Re: [Alephmodular-devel] Brainstorming on bitmaps

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

On Monday, February 24, 2003, at 06:39  AM, Br'fin wrote:
> On Monday, February 24, 2003, at 02:16  AM, Mark Levin wrote:
>
>>> Ponder... Setting the drawing context should occur seperately
>>
>> Maybe this should be changed to a stack-based mechanism (like Quartz) 
>> instead of requiring the program itself to cache and restore the 
>> previous state.
>
> I haven't seen Quartz's method, but I feel you're right. I just 
> haven't figured out who should own the drawing context yet. It does 
> seem that some other class to encapsulate drawing options is 
> appropriate. (A singleton CDrawingContext with the auto-releasing 
> method I'd mentioned?)

Very hazy notes on Drawing Context

-Jeremy Parsons

DrawingContext

A DrawingContext would own all of the high-level operations for 
operating on a buffer. For instance, using line primitives and 
displaying text.

Some systems, such as Macintosh, use a method of drawing commands that 
works as follows.
	Store the current drawing context
	Use the desired graphics port as the context
	perform drawing operations
	Swap the ports back to where they were before.
	
Would this be better encapsulated as:

	std::auto_ptr<DrawingContext> context= CBuffer.get_drawing_context()
	context.draw_line...
	context.draw_text
	(context automatically freed)
	

Or
	std::auto_ptr<DrawingContextScope> scoped= 
DrawingContext.get_drawing_scope(CBuffer)
	DrawingContext.draw_line...
	DrawingContext.draw_text
	(scope automatically freed)
	
Or something else?