Re: [Alephmodular-devel] Drawsprockets?

[Br'fin <br...@ma...>]

On Tuesday, March 11, 2003, at 09:57  AM, Woody Zenfell, III wrote:

> On Tuesday, March 11, 2003, at 12:57  AM, Br'fin wrote:
>
>> Is there yet a more appropriate API than DrawSprockets for going 
>> right to the display hardware of MacOS X? Right now CDisplay is very 
>> centered towards the way AlephModular currently uses a single back 
>> buffer that is always getting copied forward (A window back buffer 
>> and appropriate flush to display calls) I'm sure this will turn up 
>> cases of flicker (Places where info needs to be updated on both 
>> buffers not getting updated properly) Hooking it up with 
>> DisplaySprokects should help flush out those areas in need of 
>> improvement. But I really don't know if DrawSprockets is the Apple 
>> recommended way of going about this anymore.
>
> Maybe it's because I just got up, but I don't see how this scheme 
> could result in flicker?  There's a strict hierarchy of the back 
> (offscreen) buffer receiving every update from the program and the 
> front (onscreen/frame-) buffer getting copies of the back buffer... so 
> every back buffer you render in has the very most recent rendering 
> changes you've made, no problems.
>
> Now in a page-flipping environment, where you render to the back 
> buffer and then flip it to the front, making the old front buffer your 
> new back buffer, well your new back buffer doesn't have whatever 
> changes you just flipped to the front, and if you don't render the 
> changes again to your new back buffer, those elements will flicker 
> back and forth every time you flip from now on.

Right, the current environment is not page-flipped. But I don't know 
how DrawSprockets or SDL or Windows handles fast screen updates. 
DrawSprockets appears to use concepts of fore and back buffers with a 
swap command. CGDirectDisplay actually seems to act like the classic 
Mac-way of handling fast screen updates, go figure. :)

If any one of those environments is page-flipped, then I bet that I 
will find some flicker problems. Most notable around the HUD which has 
classically been drawn to the screen_window instead of using the 
world_pixels that actual rendering used.

> FWIW my suggestion (not terribly clever, but it should work) for 
> correctly doing occasional updates to nonmoving screen elements (like, 
> the whole oxygen display etc.) in a page-flipping environment is to 
> use a dirty count (set to 2 in a double-buffered page-flipping scheme, 
> decremented once per drawn frame) instead of a dirty flag, so you 
> redraw the element once per buffer before it's clean.  Forcing a draw 
> (e.g. update_interface(NONE), right?) would have to set and use the 
> dirty count also to make sure the forced draw goes into every buffer.
>
> Right?

I certainly agree with the concept of a dirty count.  And I do think 
you're right.

-Jeremy Parsons