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 <[EMAIL PROTECTED]>:
On 5/22/07, Aaron Oxford <[EMAIL PROTECTED]> 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 - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
_______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
