Re: [Alephmodular-devel] Drawsprockets?

[Woody Z. I. <woo...@sb...>]

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.

(Of course, page-flipping is probably preferable in most cases, because 
flipping the buffers is much less expensive than blitting the back to 
front - and of course you're making that savings every frame.  OTOH it 
does introduce potential flicker problems with areas that are not either 
completely redrawn every frame or completely static, and it's almost 
certainly not an option in a windowed mode.)

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?

Woody