Re: [Alephmodular-devel] Brainstorming on bitmaps

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

On Monday, February 24, 2003, at 01:16  AM, Mark Levin wrote:

> Are you talking about the original MacOS LockPixels() concept (which 
> IIRC was meant to protect pixmaps from memory manager housekeeping) or 
> some sort of mutex for multithreaded drawing? The former is probably 
> obsolete on everything except OS9.

I gather more like the latter.  For example, DirectDraw in Windows (and 
indeed SDL) require that a pixel-buffer ("surface") be locked before 
it's read from or written to.  This is because the video hardware may 
have various blits outstanding, some of which may involve the surface... 
and so to ensure consistency, access to the buffer must be synchronized 
with the blitting hardware.

Note the IDirectDrawSurface->Lock() interface lets you (optionally) 
specify a portion of the surface to lock.  So in theory blits that 
involve other parts of the surface could continue while you do your 
operation, etc.  (SDL_LockSurface() might let you specify a portion 
also - don't remember offhand.  Probably so though, since my impression 
is that SDL_video most closely resembles DirectDraw.)

Indeed DirectX (DirectSound does this too) has a habit of providing 
pointers to raw data (and other relevant descriptions of the raw data) 
only in response to Lock() calls, to encourage users to always Lock 
before doing direct writing or reading.

This way also I can Lock() my gBackBufferSurface in an odd-numbered 
frame and get a pointer into one buffer in a double-buffer structure, 
then call Lock() with exactly the same value for gBackBufferSurface in 
an even-numbered frame and get a pointer into the other buffer.  My code 
doesn't have to track the flippings.  (Indeed DirectDraw has built-in 
support for generalized flipping chains, so moving from double- to 
triple-buffering is a matter of merely changing the value "2" to "3" in 
the call that sets up the "primary surface"... well assuming I redraw 
the whole screen every frame of course.)

And, well, normally the primary surface "owns" all the surfaces in its 
flipping chain, so they all get deallocated when the primary surface 
does.  But, since surfaces implement COM reference-counting, I can do 
gBackBuffer->AddRef() so that I can gBackBuffer->Release() later without 
worrying about whether the surface was created by the primary surface 
(as in a flipping chain) or by me (as when I'm maintaining my own 
offscreen buffer for blitting to a window, say).

Whoops, too much information.  Sorry.  Go read the DirectX docs and/or 
SDL docs if you need more detail.  :)

> Rectangle representation: Do we use OS9-style absolute boundaries 
> (left/top/right/bottom) or "relative" rectangles (x/y/width/height)? Is 
> the origin at the physical top or bottom of a buffer? (Carbon and 
> OpenGL disagree on this last bit, which has caused me its share of 
> confusion too. How do Windows and SDL work?)

Both assume the top-left corner is 0,0 (and that positive X goes 
rightward and positive Y goes downward).  (I think.  :) )  Err, for 
Windows there I was thinking DirectDraw.  Windows GDI (sort of like the 
Toolbox) OTOH likes to put origins in the lower-left (and have positive 
Y go upward).  I think.  Sometimes.  Or something.  That way makes sense 
I guess if you consider the conventions mathematicians etc. use... but 
given that windows typically resize in the lower-right-hand corner, 
anchoring the origin at the top-left makes more sense to me.  Shrug.  
(But this resizing convention probably comes from our language's 
left-to-right, top-to-bottom reading order.  Shrug.)

DirectDraw uses tlrb whereas SDL IIRC uses tlwh.

One could always create a new Rectangle class whose objects can use 
either convention (probably by storing only one internally (maybe 
determined by what the underlying target API prefers?) but 
providing/taking values in either scheme for convenience/compatibility).

Woody