[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mozilla-qt
Subject:    Re: nsIRenderingContext::Begin()/End()
From:       saari <saari () netscape ! com>
Date:       1999-08-31 23:27:39
[Download RAW message or body]

I like it, but don't we already have something similar we call? I could swear I
saw something similar before...

So can these calls nest? Will the following do the right thing?

BeginDrawing(surfaceA)
  BeginDrawing(surfaceB)
  EndDrawing(surfaceA)
EndDrawing(surfaceB)

Patrick Beard wrote:
> 
> I would like to propose that we add an explicit call to
> nsIRenderingContext that tells it which drawing surface to use. This is
> needed on the Mac, so that we can manage GrafPorts correctly. And
> looking through the Qt documentation (using SeaMonkey, no less) I came
> across the QPainter class[1], which does precisely this. In Qt, one says:
> 
> QPainter painter;
> painter.begin(someWidget);
> // do some drawing.
> painter.end();
> 
> I think a similar operation should be defined for nsIRenderingContext so
> that we can tell it where it should start rendering, and when to stop.
> This enables all sorts of optimizations, such as graphics pipelines,
> postscript buffering, etc. Essentially, the following calls would
> bracket all uses of an nsIRenderingContext to do drawing:
> 
> /**
>  * Begin drawing in this rendering context, using the provided drawing
>  * surface. It is illegal to have more than one rendering context drawing
>  * in the same drawing surface at the same time, and it is also illegal
>  * to have more than one rendering context drawing at the same time.
>  */
> NS_METHOD BeginDrawing(nsIDrawingSurface* aSurface);
> 
> /**
>  * Notify the rendering context that drawing is finished. This permits
>  * flushing of any graphics pipelines, and may free system resources
>  * if appropriate.
>  */
> NS_METHOD EndDrawing();
> 
> This will have very little impact on existing code, as this kind of
> operation will only occur when a rendering context is being prepared to
> draw into. Here's an example of how this would be used:
> 
> update event comes in
>   gfx paint event gets created with onscreen rendering context
>     offscreen rendering context created
>       offscreen.BeginDrawing();
>         view(s) paint offscreen.
>       offscreen.EndDrawing();
>       onscreen.BeginDrawing();
>         onscreen.CopyBits(offscreen);
>       onscreen.EndDrawing();
>     offscreen.Release();
>   onscreen.Release();
> 
> This is easy to understand and probably easy to implement on almost all
> graphics system.
> 
> One deficiency of this is what if a client wants to use multiple levels
> of buffering? If the client gets called with the rendering context
> already having had BeginDrawing() called, can the client legally call
> BeginDrawing() again on a different drawing surface? This should
> probably be possible, so an explicit internal stack of drawing surfaces
> will probably be required.
> 
> Thoughts, comments are hereby solicited.
> 
> References
> 
> 1.  http://www.troll.no/qt/qpainter.html, documentation of Qt's QPainter
> class, which sets a precedent for having a Begin/End like functionality.

[prev in list] [next in list] [prev in thread] [next in thread]