Changes from 1.2
- font cache for Linux speed problems
Great! I hadn't known about this, but it's nice to see.
A couple of people on this list have been working on multiple
bitmaps for
the background (grid, labels, legend) and foreground plotting in
wxPyPlotbecause they felt that replotting the background for each
time was slowing
things down.
Well, that's not the only reason. At the moment, all I did was one extra
bitmap for the axis and all, and then the data itself can be draw
separatly. I did think that having a bitmap for the legen could be
nifty, as then it would be easy to drag it around the plot, but that
would only make sense if there was a level of interaction involved anyway.
I could not understand this because I felt that
backgrounddrawing was only a small percentage of the time for large
numbers of data
and this was not really an issue.But I think the light just came on thanks to Eric Blossom!!
Differencesbetween Windows and Linux again!
FWIW, we're using wxPyPlot to plot real time data with a refresh rate
of 25 Hz. Without this patch, the X font server ends up sucking up
about 70% of the CPU on a 1.7 GHz pentium. With the patch applied,
the font server is out of the loop.
Hmm. I never noticed this per se, but I did test mostly on Linux, and it
was definately a problem to do this sort of thing. Caching the fonts
sounds like a great idea. however...
After some profile testing on *windows*, I confirmed that drawing the
background takes 8-10 % of the time. The rest of the 90%+ time is
takendrawing points and lines (25,000 squares, 25,000 lines). On
my 1GHz Athlon
this takes roughly .3 sec.
Here's the difference. When drawing 25,000 squares, you're probably
right that the axis drawing is not a big deal. However, I introduced the
extra bitmap when trying to get fast an smooth updates with a thousand
or so points with no markers, i.e. one (or maybe up to four) call of
DC.DrawLines() with 1000 points, which is MUCH faster than 25,000
DrawRectangle() calls. In this case, the time it takes to calculate and
draw the axis will probably be larger than drawign the data. I do admit
that I haven't carefuly profiled this yet. The problems I did see may
have been caused by the font issue, but I doubt that that's all of it.
Windows, but would like users to test it out under Linux to see if
there is any speed improvement.
I can't do that now, but I'll try soon, I hope. I'd like to see what
other folks find. Peter, I'd like to here how wxOcilliscope works with
this version. If anyone does try: see what kind of a frame rate you can
get with 1000 points or so.
If I have misunderstood the problem, please let me know.
Well, the only misunderstanding is that we're only concerned about
perfomance with LOTS of points.
Frankly, I'm not entirely sure that the extra buffer is worth it, but
that was easier than doing it the way I think is right: separating out
the "figure how to draw" code from the "draw" code.
wxPyPlot was clearly designed with the idea that it would be used to
creat a plot, then perhaps a whole new plot with totaly different data,
rather than a single plot with the data updated frequently, but the rest
of the plot staying the same. I think with a little re-structuring, it
could do both well.
While I admit I havn't profiled carefully, it just seems silly to
compeletly re-calculate and draw all the dimensions, etc of the axis,
labels, etc, every time you re-draw. If the whole thing could be
calculated, then stored, and only the actual drawing re-done, it coudl
be much more efficient. As a first step, all we'd need to do is save the
data about how the gridlines and/or tick marks are drawn. Then, instead
of using the extra buffer, the DrawData() method could just re-draw the
gidlines with a few DC calls and then ReDraw the data. This would remove
the need for the extra buffer, and be almost as fast as the blit.
However, what is wrong with the extra buffer? I think it's a pretty
elegant solution, easy to do, and in fact, done. Unneccessary
optimization to save memory is just as bad as unnecessary optimization
to save computation.
In any case, let's see how the speed thing plays out with the fixed font
code on Linux.
By the way, as a related note: Profiling drawing code on Linux is a
difficult, because X is asycronous: you time how long it takes the
program to tell X what to do, not how long it takes to do it. This can
be quite different for complicated drawings: I 've noticed it
particularly for large polygons.
I certainly rathre not forkl wxPyPlot: I'm sure we can find a solution
we all like.
-Chris
···
From: "Gordon Williams" <g_will@cyberus.ca>