[wxPython-users] GCDC vs DC

[Christopher Barker]

Chris Mellon wrote:
> Drawing using wxGC can be very very fast when you ...

Good news.

> leverage the ability to re-use paths with  the transforms that wxGC
> exposes because it lets you move the math out of python and into the
> heavily optimized native implementation.

What math? There is math if you need to scale stuff (though if you use
Dc.SetUserScale then Python's not doing that math either. In
FloatCanvas, I use numpy to do the scaling and shifting math, and I
haven't profiled carefully, but I'm pretty sure the math is Much faster
than the drawing.

I was concerned about the time to takes to transfer python data types to
C++, and the DrawXXXList methods are the result of that. However, it
really only makes a difference for DrawPointList (and maybe
DrawLineList), as it turns out that the drawing itself really is the
bottleneck for more complex objects (polygons, etc.). That makes some
sense -- think about the computation it takes to draw and fill a polygon!

How long does it really take to create a path, vs. to draw it?

So far, what I've seen is major performance degradation when switching
to GraphicsContext -- though I do admit that those have being naive
translations.

> It does, however, require a very different drawing model.

Which is key, I guess. Do you have any examples of performance
comparisons of DC and GraphicsContext where the GraphicsContext code is
written carefully?

> As the underlying platforms move more toward native vector everything
> you might even end up with a gain -

This is likely true -- the wxMac version uses CoreGraphics, which is
using a drawing model (displayPDF) that is quite similar to
GraphicsContext, and would hope that Apple is making sure it is well
optimized!

However, the current DC implementation is a Vector implementation, just
not nearly as sophisticated a one.

> Gtk in the future is likely to use cairo for all it's drawing,

Right, so DC calls will be translated into Cairo calls anyway, and
GraphicsContext is very similar to the Cairo API, so it can't be any slower.

> and raster operations will be piped through it. Sort of the reverse
> of the current wxGCDC penalty.

This implies that the current wxGCDC implementation used GraphicsContext 
to draw each object on a bitmap, then blits that bitmap to the DC -- 
which would, indeed, explain the performance hit!

I really do need to play with GraphicsContext more -- I sure so hope I 
can get decent performance out of it.

-CHB



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov