I need another pair of GTK3 skilled eyes to help me find the drawing performance issue in my glinegraph-cairo project. It's a GtkWidget I extracted from 'GApcMon' back in 2007 and I wanted to upgrade it from Gtk2 to Gtk3. The upgrade process was painless and I think I've covered all the bases.

The issue I'm having is in the GtkWidget#draw, GtkWidget#configure-event callback routines. The line chart test program adds 5 data points every 5 seconds, and the chart should start plotting a line for each data point from left to right. The time it takes to draw those lines is where the performance issue surfaces. Should be no more than 300ms when 50+ data points are being drawn. Depending on the version of Gtk3 that number could be 15 seconds, or just immediately fail with a GdkWindow out-of-memory error.

I've tried two different strategies to render the draw function.

1. The classic inline method of redrawing everything inside the 'draw' callback.
2. Drawing to a side surface, and letting 'draw' paint the affected region.

I've tried using the GDK Cairo Surfaces, and a Image Cairo Surface. The GDK based surface produces the worst results, with the image surface being the most stable.

I suspect there is some coding step that I've missed involving cairo surfaces, maybe I need to mark them as dirty once their drawn on. Or maybe these is something wrong with my Object Widget Structure. Right now I'm very frustrated with GTK3.

Source for this question is here: glinegraph-cairo

Any insight or help is greatly appreciated.

I just don't see where the problem could be. I've researched several OS X related GTK issues and I'm sure OS X/Quartz's surface implementation is a part of the problem. However, OS X is just my development environment; Linux is my primary delivery platform and target. These issues are present on CentOS7, Ubuntu, and Raspbian across Gtk+-3.10 thru Gtk+3.18; so OS X issues can be ignored.

There are older GTK+2.0 versions of this widget using cairo methods and one using gdk drawing methods, located on source forge under either 'gapcmon' or 'glinegraph-cairo' and 'glinegraph-gtk', if that's helpful.

Hi,

I'm far from skilled at GTK programming but I've dabbled with it.

On my machine it seems the bottle neck is drawing the dots on the graph - cairo_arc() .

Starting out, I changed the timeout duration to 500 ms. and plotting stopped after 21 data series were plotted. The program continues to run using 100% of one cpu core but puts nothing on the screen.

In contrast, after commenting out the following line, still with the 500 ms. timeout, the app has been scrolling across the screen for ~20 minutes using 3.3% of one cpu core. Don't know enough about GTK to offer a solution, but hopefully this will point you in the right direction.

EDIT: Just occurred to me - "360 * M_PI"?

norobro,

Thanks for the feedback. I had not discovered which statement was the the biggest time consumer. Plus I will have to take another look at "360 * M_PI", hehe.

I have tested on versions Gtk+-3.10.2, 3.16.6, and 3.18.9. Only 16.6 performed decently. Having one version be performant caused my to back off deep statement analysis and suspect GTK itself. I also noted that resizing the window to twice it's size helps stabilize the drawing results.

looking into "360 * M_PI" now; should likely of been "2 * M_PI"

James,

norobro,

M_PI was the root cause. I've now able to use the standard cairo surface from '#gdk_window_create_similar_surface()' as the offline surface for drawing, which performs satisfactory on all versions of GTK3. The typical performance of the 101 data point is averaging 15 milliseconds for the TOTAL draw routine. This is excellent! I'll update the repo with these changes.

a Big Thanks to you for spotting that. I think we are done here (unless you've spotted something else)

James,