| Re: [AD] 4.3 display update methods |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Thursday 10 August 2006 02:51, Peter Hull wrote:
> FRONT BUFFER: the visible window being shown
> BACK BUFFER: the destination for all drawing operations.
> (this doesn't imply any implementation, they could be the same thing,
> as it is now for the 4.2 'screen' bitmap)
I'd vote for these two to always be seperate (eg. the back buffer will never
be the front buffer). In worst-case scenario, it can be a memory bitmap.
> IMMEDIATE: means that drawing appears straight away
> NOT IMMEDIATE: no drawing is visible until al_flip is called.
These should only be implied depending on which buffer (front or back) you
draw to, respectively, and not need an explicit mode set for it. Drawing to
the front buffer may still require a flush-type call, though (eg. glFlush,
XSync, etc).
> FRONT BUFFER RETAINED: Whatever is visible will remain even if the
> window is covered and uncovered. You will never receive repaint events
> from the OS.
> FRONT BUFFER NOT RETAINED: The app will receive repaint events from
> the OS, which may be the whole buffer or just a sub-region.
Allegro itself shouldn't need to worry about retaining the front buffer. At
most, it could be implemented as a generic driver that works on top of an
actual system driver, and provides no acceleration or hardware capabilities..
but I think that's a little out of scope for Allegro to do.
> BACK BUFFER RETAINED: After a flip, whatever had been drawn remains so
> you can draw on top of it
> BACK BUFFER NOT RETAINED: After a flip, you need to redraw everything.
A retained back buffer shouldn't be gauranteed, ever. It limits Allegro in
what it can pick for best performance, lowers performance of some drivers,
and is completely unavailable on others.
> X does not retain the front buffer?
X and OpenGL.