kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> Marco Serantoni wrote:
>> As was requested, i've done a trivial benchmark, i've taken a file from wxWin tracker and readapted to do a trivial test just to begin to taste the difference of times of the two approaches.
>>
>> The test does 100000 lines in a square of 100x100.
>> For the wxGC 
> 
> 
> 
> wxGraphicsContext?
> 
> 
> 
>> i've add 10 graphicspaths to begin to mimic which is a CAD usage.
>>
>> This is a preliminary test, there is LARGE room for improvement.
>>
>> This test requires a full version of Boost library.
>>
>> --
>> Marco
>> 
> 
> Thank you. 
> 
> What platform are these results on?
> 
> We know that wxDC sits on top of wxGraphicsContext on a MAC, so we'd 
> expect wxDC to be slower on a MAC since: 1) it is a longer code path and 
> 2) does not combine line and move primitives for a common ->DrawPath().
> 
> 
> Just curious about:
> 
> wxGraphicsContext & inner( *context ); 
> 
> It is unneeded, and is purely an alias for context.
> 
> 
> boost::scoped_ptr< wxGraphicsContext >
> 
> 
> Would not be the best wrapper for a "wxGraphicsContext*" if we were 
> going to use a construct like this everywhere.
> 
> 
> Here is an alternative that would read far better.
> 
> 
> class GC
> {
> 
> wxGraphicsContext* ctx;
> 
> public:
> 
> GC( wxDC* )
> {
> // set ctx here by creating getting a wxGraphicsContext from wxDC
> // (exercise for reader)
> }
> 
> ~GC()
> {
> // I assume this is needed:
> delete ctx;
> }
> 
> // inlined for speed equivalence
> wxGraphicsContext* operator ->()
> {
> return ctx;
> }
> 
> }
> 
> 
> When the object goes out of scope the destructor is called automatically.
> 
> 
> {
> wxDC dc;
> GC gc( dc )
> 
> :
> gc->DrawPath()
> 
> // destructor called here.
> }
> 
> 
> The wxDC could possibly also be put in GC too, to hide its ugly existence.
> 
> If GC to hold and hide wxDC:
> 
> {
> 
> GC gc()
> 
> :
> gc->DrawPath();
> 
> // GC destructor called here automatically
> }
> 
> 
> It would be nice to have some tests like this on other platforms. I 
> can do Linux in the next couple of weeks.
> 
> The Windows platform could be tested for both gdi+ and cairo.
> 
> We need to double check that none of the lines in the test are being 
> drawn on top of each other. I think would give dramatically different 
> results.

See the attachments for the results I got on the same computer to
compare gtk/cairo performance versus msw/gdi+ performance. I modified
Marco's program to use a single wxGraphicsPath instead of 10 and removed
the grid since it was not drawn using wxDC. I thought this might be a
bit more sensible comparison. Marco's results on OSX are what I
expected. On OSX wxDC == wxGraphicsContext so Marco's test proves that
using wxGraphicsPath to do the drawing versus calling DrawLine() 200,000
times saves a lot overhead. On gtk/cairo and msw/gdi+ the story is
different. Although there is an order of magnitude performance
decrease, gtk/cairo is probably usable. However, the the msw/gdi+
situation is bleak. I cannot see how msw/gdi+ could ever be made usable
for Kicad (or anything else for that matter). The msw/cairo combination
still needs to be investigated. I'll try to test this over the next
week or two when I get some free time. I may also try to modify the
example to use SFML if it isn't too much of a hassle to see if it lives
up to it's name.

It's looking like Manveru was correct about GDI+ performance. It is
also looking like I may have wasted my time moving the coordinate
transforms to wxDC if we can't use wxGraphicsContext due to performance.

Wayne

> 
> 
> Dick

 --------------060801020001040104090609 Content-Type: image/png;
name="msw-gdiplus.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="msw-gdiplus.png"

[Attachment content not displayed.] --------------060801020001040104090609 Content-Type: image/png;
name="linux-cario.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="linux-cario.png"

[Attachment content not displayed.] --------------060801020001040104090609 Content-Type: text/plain;
name="wxTest.cpp"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="wxTest.cpp"

[Attachment content not displayed.] --------------060801020001040104090609--