kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #04254
Re: wxDC & wxGraphicsContext Test [2 Attachments]
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
"emmedics4" <marco.serantoni@...>
-
Date:
Wed, 17 Feb 2010 15:56:14 -0000
-
In-reply-to:
<4B7C0154.6080109@...>
-
User-agent:
eGroups-EW/0.82
--- In kicad-devel@xxxxxxxxxxxxxxx, Dick Hollenbeck <dick@...> wrote:
> Marco Serantoni wrote:
> > As was requested, i've done a trivial benchmark, i've taken a file fromwxWin 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?
Yes, wxGraphicsContext.
Square is 200x200 with the last version.
> > 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.
> 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().
The results are for Mac, doing it in virtual enviroments is unusefully, i can test on bare iron only for Solaris SPARC.
Also if was a longer code path, the 4x is justificable only with the "packaging" of primitives and partially HW acceleration i think.
Testing it on other platforms will solve the dubt.
We are not testing the other "dirty things" could be done with zoom and grid: We could precalculate the grid on that context and "reuse" it.
> 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.
[..]
> When the object goes out of scope the destructor is called automatically.
> 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
> }
Was only a testdrive of the differences of time for doing the same things, not indeed an example on the code will be structured.
In this test we wish to avoid to measure construction and destruction times, could lead on NOISE and erroneus measure.
> 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.
Jep is what i was thinking about, i've posted the code at this purpose.
> 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.
Indeed doing 200000 lines in a 200x200 square includes overlapping lines, you should also remember that in wxGraphicsContext the trasparency is enabled so i don't think there is an aliasing semplification.
You think could be enough use in wxGraphicsContext, coordinates with decimal numbers for example to avoid this problem ?
Anyway if you have a sample of code on how better test you are more than welcome.
--
Marco
References