Re: [AD] 4.3 display update methods

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Wednesday 09 August 2006 06:38, Elias Pschernig wrote:
> In this latter mode, it would not be a problem if graphics commands
> would work on the front buffer, but also not a requirement. A mode where
> updates are required to go only to the front buffer (like when drawing
> to 'screen' in 4.2) seems unneeded to me.

I agree with the second part, but I'm not sure I like the idea of drawing to 
the front buffer being a driver-defined capability. Is there a driver that 
doesn't let you interact directly with the front buffer? Is there a reason to 
not require such a thing of the driver? Being able to get window invalidation 
events would be mostly worthless if you might not be able to draw to the 
front buffer to clear it up.

> Anyway, for actually implementing the first new reference driver, I
> think it will be enough to have the normal/retained mode and nothing
> else.

What, exactly, do you mean by a 'retained mode'? Is it a mode where everything 
drawn to the backbuffer is copied to an internal memory bitmap? If so, as I 
mentioned before, it shouldn't be Allegro's place to do this, especially if 
it's going to handle hardware acceleration.

Imagine that you have a bitmap in VRAM, and you blit that to the backbuffer, 
which is also in VRAM. How would the retention buffer deal with this? Would 
it have to pull the bitmap from VRAM to blit to normal RAM? Or even have a 
copy of all VRAM bitmaps in system RAM (wasting memory) and just blit that? 
In either case, you lose the acceleration. Now imagine you can enable AA, or 
do scaling with linear filtering, or other such things. Having to duplicate 
this in software for a retention buffer would completely negate the 
acceleration, not to mention bloat the lib by having to implement these 
things that are best left to hardware.

If the user is doing double-buffering, they'll be filling the backbuffer to 
refresh the screen anyway. If they're drawing directly to the front buffer, 
they should watch for invalidation events and redraw the areas as needed (it 
would be up to them to decide if they want to double buffer manually, or just 
redraw the affected areas as they were originally drawn).




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/