Re: [Alephmodular-devel] Brainstorming on bitmaps
Status: Pre-Alpha
Brought to you by:
brefin
From: Br'fin <br...@ma...> - 2003-02-25 04:45:43
|
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? |