GNOME Bugzilla – Bug 314211
Glitches in pie charts
Last modified: 2006-11-15 05:27:56 UTC
Windows version, 1.5.3-rc1 I sometimes see strange glitches in the about dialog graph. It only seems to happen when the first credited person is someone who gets the whole pie (eg only "Documentation" or "Scripting"). I'll attach some fascinating screen shots in a moment.
Created attachment 51149 [details] screen shot 1 (documentation)
Created attachment 51150 [details] screen shot 2 (scripting)
To reproduce: 1. File/About 2. Look at the graph for about 10 seconds (look for glitches) 3. Press OK 4. Go to Step 1
Step 1 should be Help/About, not File/About.
I don't see this on Unix. Assuming Win32 only.
I do see it on unix from time to time, but I do not found how to obtain it reproductively.
Created attachment 51417 [details] another screenshot To reproduce, create a pie with only one value, and change the value several times. In my sample, A1 contains =rand(), and I type F9 as many times as necessary to reproduce the bug.
Created attachment 51476 [details] test.gnumeric I made a test file using the instructions from the above post. I added a gradient fill. Just keep hitting F9 until you see the bug. You can also hold F9 down if you're impatient. Every time there's a glitch, the console says x_order_2: colinear! x_order_2: colinear! (see bug 308305) However, there isn't a glitch every time the console says the colinear thing.
Confirmed. Entering 0.7760846473312053 [where gnumeric afterwards will not show the final 3] seems to trigger this.
Created attachment 51567 [details] test2.gnumeric I made another (very silly) test file with lots of pie charts. I noticed that you don't need the =rand(), any number will do (I picked 1). The number doesn't need to change, refreshing is enough. Sometimes I see the bug after resizing a chart. This is strange: after exiting Gnumeric completely, loading the test file always shows the glitch in the same 3 pies, and after hitting F9 I get another set of pies that's always the same, and so on. I tested to up to 5 refreshes and compared the results: always predictable. I don't think it's as random as I first thought. I can't reproduce with 0.7760846473312053 though (win32)
Jean: are we adding random pertubations anywhere?
I don't think so. The problem might come from libart; clipping does not always work as it should. We should try with the cairo renderer to see if it is also affected. Emmanuel might have some ideas about that, he will be back next week. The bug does not affect 1.4.x (at least, I could not reproduce with 1.4.3).
~/gnome/goffice> find . -name '*.[ch]' -print | xargs -n100 grep pertu ./goffice/graph/gog-renderer-pixbuf.c: path1 = art_vpath_perturb ((ArtVpath *)path);
This code and the next 6 lines were added in order to fix http://bugzilla.gnome.org/show_bug.cgi?id=159368 . That's what gnome-print does for correct rendering of transparent areas. If you try to remove the perturbation part, this time you'll get reproductible glitches in transparent areas or even crashes.
We have switched to cairo and that fixes this issue.
*** Bug 375233 has been marked as a duplicate of this bug. ***