kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #04255
Re: wxDC & wxGraphicsContext Test
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
Wayne Stambaugh <stambaughw@...>
-
Date:
Wed, 17 Feb 2010 11:29:50 -0500
-
In-reply-to:
<4B7C0154.6080109@...>
-
User-agent:
Thunderbird 2.0.0.23 (Windows/20090812)
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--
Follow ups
References