Re: [Alephmodular-devel] More to muse over. Display Abstraction

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

[pixel-doubling (actually quadrupling I think but let's overlook that)]

What about making a CDoublingBuffer that's sort of like your 
CClippingBuffer in that it "modifies" an existing buffer?

i.e. a CDoublingBuffer would know about an IBuffer, call it mBuffer, 
that it's supposed to double; its GetHeight() would be { return 
mBuffer.GetHeight() * 2; } and so on.

Of course as you correctly point out there needs to be some "hook" that 
lets the DoublingBuffer actually perform the doubling calculations - or 
does there?

Maybe CDoublingBuffer would cache the doubled pixels in its mCacheBitmap 
member (pardon me if I'm getting the terms wrong here) and would 
maintain a 'dirty' flag that would tell it (when someone tries to read 
from it) whether it needs to re-render the doubled pixels to its cache 
or can just provide data straight from the cache.  Rerendering would of 
course clear "dirty".

Now the sticky bit is setting "dirty".  For that you probably want to 
use some kind of "Observer" pattern so that a buffer can announce when 
its bitmap is modified, and interested parties can register with it to 
be given notification.  So the CDoublingBuffer would be an observer of 
its mBuffer base-buffer; the latter would announce "got changed" when it 
gets Unlocked, say (right?  IIRC you may only render into a buffer's 
bitmap if you lock it first?  or do you actually lock (part of) the 
bitmap itself?  in that case the buffer is probably an observer of its 
bitmap, and the bitmap notifies when it's Unlocked(); the buffer can 
then notify that its bitmap changed, which lets the observing 
CDoublingBuffer set its dirty flag).

Of course hmm another issue there is that the CDoublingBuffer's IBitmap 
probably doesn't want to have other people rendering in it?  Because the 
changes will be discarded the next time the buffer is rerendered?  Is 
there a notion of "read/write" vs. "read-only" IBuffers?  (e.g. 
IReadOnlyBuffer is an ancestor class of IReadWriteBuffer?  
CDoublingBuffer is a descendant of IReadOnlyBuffer but not of 
IReadWriteBuffer?)

Oh of course all the caching stuff can be skipped if CDoublingBuffer is 
only used like theDoublingBuffer->BltInto(theWorldPixelsBuffer, ...) and 
its contents typically change as often as that routine is called (both 
of which may well be the case).  Which would be nice of course because 
then you wouldn't have to keep storage around for the doubled pixels... 
but then it's probably doubly important to distinguish in the interface 
between read-only and read/write IBuffers.

Note that a temporary Bitmap could be generated if a caller wants to 
lock down the pixels (for read-only access of course, e.g. writing out a 
screenshot or something).  But there's probably no need to create this 
intermediate if we're doing a blt to another existing Buffer.

Observe that RLE Bitmaps probably want to be read-only as well, and in 
fact may have a lot of the same properties (can copy directly from one 
to somewhere else, but locking for direct pixel reading requires the 
creation of a temporary non-RLE'd Bitmap).  Actually you could have 
read/write RLE Bitmaps if you really wanted to of course, when the 
temporary non-RLE'd Bitmap is Unlocked() you could perform the RLE on it 
to produce an updated RLE Bitmap.  Or, disallow operating on RLE Bitmaps 
directly but offer routines to explicitly convert them to/from "full" 
Bitmaps.  Or something.  If you want.  Heh heh.

Does any of this make any sense?  Maybe I have an incomplete 
understanding of your scheme and how it fits into AM...

Woody