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

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

Ok, I think the entirety of your description (observers, readonly 
bitmaps) is much like one of my overblown efforts. However, I think 
your base idea is workable.

As I was reading your message I'd been thinking 'what if pixel doubling 
was an attribute of a bitmap.' But, as I thought that through, that 
would require checks wherever in buffer or what not for this attribute, 
perhaps building concealed clipping buffers or something. And no, no, 
that was too much in a different direction.

However, if there was a CDoublingBuffer, and itself was a descendant of 
CClippingBuffer, then it could accept an input area that's divisible by 
2, clip itself even more heavilly, and when it unlocks its pixels, it 
could inflate them.

This also allows the buffer to position the original clipping optimally 
for not mis-overwriting when inflating.

... Hmm, currently to get a clipping buffer, you request one from the 
current buffer... guess you could add an attribute to that call.

CClippedBuffer::Ptr (auto_ptr) CBuffer::get_clipped_buffer( dimensions, 
attr = CBuffer::PixelStandard)

But attr could also be CBuffer::PixelQuadruple which would switch it to 
be allocating a doubling buffer instead of a normal clipped buffer.

-Jeremy Parsons

On Saturday, March 8, 2003, at 12:41  PM, Woody Zenfell, III wrote:

> [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
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The 
> debugger for complex code. Debugging C/C++ programs can leave you 
> feeling lost and disoriented. TotalView can help you find your way. 
> Available on major UNIX and Linux platforms. Try it free. > www.etnus.com
> _______________________________________________
> Alephmodular-devel mailing list
> Ale...@li...
> https://lists.sourceforge.net/lists/listinfo/alephmodular-devel
>