[wxPython-users] GCDC vs DC

[Christopher Barker]

Chris,

Thanks for the info -- it's really helping me "get" GraphicsContext Better.

Chris Mellon wrote:
> polygons and arcs not directly supported by wxDC.

Yes, I'll bet there is a major win there.

> Hit testing for non-rectangular regions.

Does GraphicsContext do this at all efficiently? For FloatCanvas, I draw 
everything to an off-screen bitmap in a different color -- it makes 
hit-testing blazingly fast (though has downsides, too). I understand 
same variation of this is common. After all, you have to do almost as 
much math to hit-test as you do to draw -- you might as well just draw.

> Numpy will obviously handle
> the math better than pure python, though.

Yes, that' does help a lot.

> wxGC also supports arbitrary
> matrix transforms, including rotation, which wxDC doesn't and are slow
> to implement in Python.

Also True -- I'd to that in numpy too..

> The marshaling isn't so much of a problem, but iteration in Python is
> much slower than in C++ (several orders of magnitude)

Not my experience -- it's not the iteration, it's what's happening 
inside each loop. And DrawXXXList takes care of that too, but again, no 
noticeable difference for complex objects.

> out of it is a big win. Psyco can accelerate python loops, too.

Yes, but I doubt it would help much if there was a wxDC call in the 
middle of the loop. Psyco could be a good alternative to numpy for the 
math stuff, though.

>> How long does it really take to create a path, vs. to draw it?
>>
> 
> In my very first SVG implementation I reparsed and re-rendered the SVG
> document from the XML with every draw. The first obvious optimization
> was to save the SVG document model and doing that saved my about 90%
> of my drawing time. 

No surprise there.

> The second optimization was to build a drawlist of
> pre-built paths and objects instead of re-creating them and that saved
> another 90%.

really? Wow! so it takes about ten times as long to create a new Path 
than to draw one? Or maybe I'm mis-understanding what it is you did.

Although, as I look at the API, it looks like building a polygon, for 
instance, requires a lot of calls to GraphicsPath.AddLineToPoint. It 
seems like a few C++ convenience functions, like AddLinesToPoint (note 
the s), would help a lot here.

> There's also a
> smaller gain from caching graphics objects - 

what's a graphics object? All I see are Paths, Pens and Brushes -- or is 
that what you mean?

> Nothing that I've benchmarked in any detail. wxGC can render a
> thousand vertex polygon in less time than you can practically measure,
> though.

Good start. I need to test on my kind of stuff I guess.

> On the other hand, with wxGC the primary *render* cost is the total
> number of pixels pushed. The exact same path will be much faster
> rendered at 100x100 vs 1000x1000.

Interesting, I agree that I've never noticed a difference with that with 
DCS, but I haven't tested for it, either.

> I believe on Gtk it does exactly that. On MSW you can create Graphics
> objects that draw directly into HDCs, but cairo on Gtk needs a bitmap.
> On Gtk, cairo draws directly into the Gtk windows backing store.

yes, but wouldn't GraphicsContext be pushing vector drawing commands to 
Cairo -- so the whole image would then get pushed to the backing store, 
which is pretty much the same as double buffering, which never made much 
a difference to performance for me -- as you said blitting is fast with DCs.

I remember you mentioning your SVG renderer before -- do you have a 
pointer to it?

Also, have you seen pyGEF:

http://sourceforge.net/projects/pygef

He started with FloatCanvas, then moved on this this GraphicsContext 
bases system -- I'm thinking of merging some of FloatCanvas with it, and 
it maybe could be mixed with your SVG work somehow.

-Chris



-- 
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