After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 310363 - Flicker in Gtk version
Flicker in Gtk version
Status: RESOLVED FIXED
Product: dasher
Classification: Applications
Component: general
unspecified
Other All
: High major
: 3.99.1
Assigned To: Phil Cowans
Phil Cowans
Depends on:
Blocks: 519278 519313
 
 
Reported: 2005-07-14 13:23 UTC by Phil Cowans
Modified: 2010-03-28 12:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Phil Cowans 2005-07-14 13:23:11 UTC
Please describe the problem:
Apparently... (someone who knows should probably say more here)

Steps to reproduce:



Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Chris Ball 2005-07-18 16:44:04 UTC
Well, here's a more concrete bug:  Dasher is far, far more jerky/flickery when
maximised than when in a small window.  Is there something we could be doing to
reduce the drawing load?  I don't see why we can draw a medium-sized window
without missing a beat but not a maximised one.
Comment 2 Phil Cowans 2005-07-18 16:55:59 UTC
One test we could do would be to disable various components of the rendering
process (ie only draw boxes, only draw text etc.) and see if any one of those
significantly contributes to the problem.
Comment 3 Phil Cowans 2005-08-07 15:20:04 UTC
(Realistically this isn't going to be fixed for 3.99.0 - it's still not obvious 
whether this is a Dasher bug, or something in GTK/Pango/X11)
Comment 4 Phil Cowans 2005-08-08 12:31:45 UTC
Here's a fun one - if we create an extra pixmap when we create the canvas
object, but don't use it for anything we dramatically improve performance (on
tiree at least). Seems that the first pixmap is faulty in some way.

A free Mars bar to whoever can work out what the hell is going on here.
Comment 5 Phil Cowans 2008-02-28 18:56:38 UTC
Additional information for new developers:

Graphics performance in Dasher is still very poor. There are two issues here, one is that the frame rate is sometimes quite slow due to excessive computation during the standard render cycle. The second is that the display is often very flickery, almost as if when transitioning from frame A to B you get the sequence

A -> B -> A -> B

The same behaviour occurs on Windows (using the navive GDI rendering API), suggesting that it isn't a low level issue, but is something related to the Dasher code itself.

This is a hard problem, but probably one of the most important outstanding bugs.
Comment 6 Aaron Larson 2008-03-17 05:02:21 UTC
I spent some time on this bug tonite.  In my kubuntu system, even with the dasher display paused, X consumes 75+% of the CPU in "system" time, and dasher takes the rest. Yikes!  I tracked the problem down to CCanvas::Display().  I don't understand the structure yet, but if WITH_CAIRO is set to 0 in config.h, then CPU consumed when paused drops to zero, and in my observation, the flickering seems to be significantly reduced.  It would be nice to have a test case that was more definitive.
Comment 7 Patrick Welche 2010-02-10 16:38:18 UTC
Does

http://git.gnome.org/browse/dasher/commit/?id=3c71ead76d5650868eead6576a56baf7c5be95d0

make things better?
Comment 8 Tobias Mueller 2010-03-28 12:41:37 UTC
Phil, Aaron, I'm closing this as FIXED as the patch mentioned in comment #7 might have fixed this issue. If it didn't, please reopen.