Graphics performance under wxGTK

[Mart Raudsepp]

On Mon, 2007-03-05 at 16:14 +0200, Damjan Jovanovic wrote:
> On 5 Mar 2007 06:01:56 -0800, olivier.corrio at gmail.com
> <olivier.corrio at gmail.com> wrote:
> >
> > Hi,
> > i have made a application on wxMSW and these application needs to
> > refresh up to 30 frame/s. So to test that before finishing it, i did a
> > simple timer.
> 
> Writing code that *needs* to refresh N times per second is a bad idea
> - you might not have the necessary system resources to do that, in
> which case the event queue keeps getting longer and longer until you
> run out of memory and your application crashes, together with probably
> many others.

I concur here in general, however paint events are somewhat special.
They are merged together on the event queue at the native toolkit level
in all popular cases afaik.
Though, you still should not do a strict interval, as it still can block
quite heavily as you've experienced. So instead of an interval, you
could do one-shoot timers at the end of the previous paint, for example.
If necessary making the time dynamic based on clock - to sync to a
certain interval if that is necessary for the behaviour.

> > On wxMSW i can easily make the timer to 20ms and to have easily 30
> > frame/s but on wxGTK it blocks the application, and this one can't
> > even respond to size event.
> 
> Probably because the size event is still far down the queue.

Resizing is known to be a bit problematic on both wxGTK and GTK+.
However in most cases it's just perceived due to the fact that common
window managers can't sync the resize with GTK+, as for the toplevel
windows border decorator to be drawn at the same time as GTK+ is
handling it, for it to look nice and not leave a bad impression when the
desktop is set to do live resizes of windows.
However, other things constitute to that, things which are different and
fixable problems - to fix them, we'd need to know what exactly is slow -
which means a minimal test application that can be easily profiled and
modified. I'm personally interested in doing such profiling and fixing,
however my time is scarce right now.

> > I use wxDC to draw on panel. Is there a
> > way to speed up the application on wxGTK ? I only use DrawText /
> > DrawRectangle on it so i don't understand why wxGTK is far more slower
> > than wxMSW. Maybe it is because of my timer to test it ?
> 
> Don't write timers that way. Stop the timer and restart it once your
> drawing code finishes. Don't allow events to stack indefinitely, it's
> really bad.

That's the first thing to fix of course, and then the performance can be
re-evaluated.
I have experience with DrawText quite a bit thanks to my own pet
application projects needs - there are things to consider to have
DrawText be quick if that's what you do most.
For both cases, it matters very much on your X server and lower level
libraries performance as well.
For example cairo-1.4 will improve some raw rectangular drawing many
times compared to 1.2 - but this doesn't matter as you are using wxDC,
not wxGraphicsContext, from which only the latter currently uses cairo
on wxGTK. But for text it ends up in pangocairo backend engine already
now with gtk+ version of 2.8 or newer and there are improvements as well
in cairo-1.4.
So the question becomes also - is it a problem of wxGTK, or something
it's built on top of. In most cases I've seen it's often just old
versions of Xorg, fontconfig, freetype, cairo and others that make it
slower than it could be if using the optimized new versions of each of
those and others.

One thing I can note about DrawText is, that when you often want to know
the width and height it drawed upon and you don't need to know that
beforehand, you can just use wxDC::ResetBoundingBox and related
functions to get that information out.
If you call GetTextExtent on the text plus DrawText afterwards, you are
effectively creating a pango layout twice together with all the kerning
and other related calculations, which is expensive compared to the
low-level functionality of what WinAPI does, and you are doing it twice
then.
The underlining problem is that we don't have a matching class for what
pango has for it - a TextLayout class. For that reason we are working
against pango (pango wants to do the layout of text, and we can't hold
onto its results for one piece of text), but it's not bad when you
reduce your GetTextExtent calls to the minimum necessary.


To sum it all up - you need to profile it before one can point at
anything in particular. I would suggest sysprof for the profiling tool
of choice - http://www.daimi.au.dk/~sandmann/sysprof/
If it points at wxGTK, we'd be happy to see what can be done.
I can also help with any of this if you come to our IRC channel.
It's #wxwidgets on irc.freenode.net - I'm with the nickname "leio"
there.


With regards,
Mart Raudsepp,
a performance freak