[Gtk-sharp-list] Tips for drawing quickly

[David Anes]

Hi Aaron.

Well, about the performance of drawing, I've been working fulltime for two
years now using C# building CASE tools in the OO-Method Research Group
(Universidad de Valencia) at
http://oomethod.dsic.upv.es/anonimo/index.aspxIn fact. I've developed
a C# Diagramming Engine for complex layout and
entity hierarchies to support BPMN, UML, OOWS, i*, etc. so I've been
fighting with drawing performance all the time. Although I've been using
System.Drawing on both Windows and Linux platforms, almost the same tricks
work with Cairo.

I will not enter here about comparing Cairo against native System.Drawing,
only showing some techniques you could use to improve 2d image rendering
performance.

The current tricks I use are:

* Use image blitting when possible: if you are drawing many complex shapes
using paths, gradients and so on, try to cache the resulting image on to a
buffer and redraw it only if needed. It's faster to blit the cached buffer
than to directly draw it every time (in native System.Drawing is extremely
fast, in Cairo-based System Drawing... maybe it could be speed up it a bit
using raw X image blitting).

* Invalidation of areas are slow: is easy to drop performance if many
invalidations are done so I've done what I call "The Invalidation Cache".
The idea is to catch all invalidated areas into a single big invalidation
area, then invalidate this area just before to draw and clear out the
"invalidation cache" for the next frame to be drawn. This greatly increases
performance!

* Draw only what is needed: in my case, I try to intersect expose events
whit drawn entities to only draw what is needed and clip cached images of
entities with the exposed areas before draw.

* Use space partitioning techniques: 2d space partitions are easy and fast,
so intersection with entities in the drawing area are very very fast,
although you must update the space partion buckets when you translate and or
modify the outline (scale, shear, etc.) of an entity.

Using all these techniques altogether makes a big difference. In fact, I run
fullscreen applications at 1440x900 wit scrolling canvas (virtual size of
5000x5000) at 60fps both in Windows and Linux (using invalidations in
windows and queueareas in gtk) and smooth entities movements with 400+
shapes with gradients, antialiasing and transparencies. In fact, I beat
Java's GEF, Poseidon and System Architect rendering canvas (all these
without antialiasing and/or transparencies) in many test cases I've done.

Hope this will help.
David Anes.

PD: I think I must write some research papers about all these techniques
joined together :D

2007/5/22, Michael Hutchinson <m.j.hutchinson at gmail.com>:
>
> On 5/22/07, Aaron Oxford <aaron at hardwarehookups.com.au> wrote:
> > I therefore submit the following very basic, more than likely biased,
> > test comparing the three-fold path of fastly drawing under Gtk# -
> > purely for interest's sake. Just open the program and resize it,
> > keeping it almost the same size but causing it to redraw and gather
> > data over a long period. On my machine, (3800 X2, 7600GT, Server2k3,
> > Gtk#2.8.3) redrawing overall happens at about 1-2 fps. The measured
> > drawing times are:
> >
> > Gdk:                    324 ms (3 FPS)
> > Cairo:                  292 ms (3.5 FPS)
> > System.Drawing: 24 ms (Badooshka)
>
> I have Ubuntu 7.04 (GTK 2.10), on a 4200+ X2 with a 6600GT. Modifying
> the program to divide my the number of expose events (i.e. to get an
> average), and dividing by 1e4 to convert from 100ns ticks to ms the
> lowest averages I can reproduce are around
> GDK: 220 ms
> System.Drawing: 200 ms
> Cairo: 380 ms
>
> So no, it doesn't look like your results are specific to Windows.
>
> OTOH, I find Gnumeric usably responsive, even on a 1.4GHz Windows laptop.
>
> --
> Michael Hutchinson
> http://mjhutchinson.com
> _______________________________________________
> Gtk-sharp-list maillist  -  Gtk-sharp-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/gtk-sharp-list/attachments/20070523/60a43c8d/attachment.html