Re: [Alephmodular-devel] More to muse over. Display Abstraction
Status: Pre-Alpha
Brought to you by:
brefin
From: Woody Z. I. <woo...@sb...> - 2003-03-08 17:41:27
|
[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 |