Re: [AD] 4.3 display update methods

[Elias Pschernig <elias@xxxxxxxxxx>]

On Wed, 2006-08-09 at 07:10 -0700, Chris Robinson wrote:
> 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.

Well, you still would have the update_rectangle call, so that's where
the XSync would be done. If we require it to be a "front buffer", then
each single putpixel command in Allegro would need to call XSync, or
else we need again something weird like the line-by-line update hack in
4.2. By requiring the update_rectangle and leaving it up to the driver
when to actually display the result of graphics commands, this can
always be solved in the driver in a clean way.

> > 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.

As I understand, the retained just means that you need to call al_flip
before graphics updates get visible. So it is retained in that al_line
won't immediately make a line appear, but only the next al_flip.

> 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.

Hm, that would be another form of retained mode. I was thinking about
directly doing reads from the display with OpenGL, and never maintaining
any internal buffer. We would use GL_NEAREST while in allegro mode, so
nothing unexpected should happen. If users use OpenGL, then I don't
think it's a problem letting them deal with effects like AA themselves.
And if you make a game which uses e.g. getpixel(screen,x,y) for
collision detection, then you could simply use your own memory buffer
and blit that (either before al_flip in normal mode, or before
update_rectangle).

> 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).

Yes, just how I see it.

-- 
Elias Pschernig