If you draw directly to the screen, you will have flickering images whenever an object needs to draw over itself or have it's background redrawn.
You also have flickering if you use per-widget bitmaps - the drawing operation then becomes the blitting of the widget bitmap to the screen.
Buffering widgets does not work like that (i.e. one bitmap per widget). It works with a background bitmap that all widgets are drawn onto, and then the final result is displayed, either via page flipping or blitting.
Why would you want to redraw every single widget when you could just blit a stored copy of the gui panel into place as necessary?
Because bitmaps take a lot of memory, and you will usually have to redraw the bitmap anyway.
The EXPOSE event may tell you what part of the screen is dirty, but if A5 is using page flipping and you update one page and flip, that update is lost on the second page.
Perhaps. I haven't seen it though, in my current demos. Which means that A5 doesn't use page flipping, it just blits the back buffer to the front buffer.
Premature optimization anyone? The overhead added by an update function is completely negligible. If your timer is running at 60Hz, then you will never be more than 1/60 of a second behind the actual time you wanted. No human can even tell the difference between 60/60 and 61/60 of a second.
It's noticeable, because there are other delays too: the thread that implements the timer, the putting of event in the queue, the waking up of the thread etc. These may amount to more than 20 milliseconds, especially on Windows where the default timer accuracy is 10 milliseconds.
The main problem though is that a thread waking up every 16 milliseconds. It's a resource hog.
Of course it is. Only the widgets that actually use the update function will ever redefine it. The rest of the widgets don't have to do a single thing with it.
But the whole widget tree will have to be notified every 16 milliseconds of the timer. Isn't that a performance issue?
I really just disagree with you on this. This all works perfectly fine in my GUI, and adding in 5-10 lines of timer code is not too much to ask a user to do if they want animations.
Well, it may work for you, but if you try to do a simulation where the simulation state is updated every 100 milliseconds, and you have a thread waking up every 16 milliseconds, you will notice many hickups in the simulation thread.
I want to avoid any possible performance issues in my gui, since I'd like to use it in my simulations. Perhaps your needs are different, but even if they are, I don't see how saving up resources is a bad thing.
Why make the limitation of one animation at a time?
I will not make such a limitation. I was just referring to the most common use cases for timers on a gui, i.e. blinking cursors and automated scrolling views.
According to al_flip_display documentation:
Pointers to the special back and front buffer bitmaps remain valid and retain their semantics as back and front buffers respectively, although their contents may have changed.
So the expose event works because the back and front buffers remain back and front buffers after a flip.