GNOME Bugzilla – Bug 359243
Disappearing rows in GTKDFB with checklists
Last modified: 2007-05-01 15:18:10 UTC
Please describe the problem: Hi as this screenshot [1] shows, checkboxes and corresponding strings are sometimes misdisplayed or not displayed at all in GTK applications. Tests was done with today's GTK+ from cvs, cairo 1.4.2, dfb 0.9.25. I know this looks like a minor bug, but it's ATM a really annoying bug in the d-i. Attached to this mail there is a small application that will ease experimenting with a list of checkboxes. thanks Attilio [1] https://debian.polito.it/downloads/bug_385026.png Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 73934 [details] A small app to test with checkboxes
If the application uses gtkclist/gtkctree its not supported. Clist updates its list outside of the paint loop. Its deprecated also. Basicaly no deprecated functionality is supported. The gtk components need to be re-written to use beginpaint/endpaint. If this is the cause then a bug needs to be filed agianst those. Under directfb you cannot paint outside of gdk_window_begin_paint_region/rect gdk_window_end_paint
I looked at the app it does not use the ctree. I suspect that the regular tree is also painting outside the begin/end paint methods. We can't support this under directfb. I looked through the source and it seems correct for gtktree using only invalidate to cause the paint loop to run. But its a very complex widget and I don't understand all of the ways it paints. I'll look into it but if you can come up with a simple example that does not use tree then it will help a lot or prove/disprove that tree paints outside of the begin/end paint. If I could talk with the widget maintainer for tree it would be very very helpful. Mike
Created attachment 74000 [details] a more generic way to reproduce this bug As reported by Rui Lopes <rgl AT ruilopes dot com>, this issue is more generic: try opening the gtktreelist and move the mouse on top of the popped up window: text strings will become fuzzy and when you move between rows the bug can be easily reproduced.
(In reply to comment #4) > Created an attachment (id=74000) [edit] > a more generic way to reproduce this bug > > As reported by Rui Lopes <rgl AT ruilopes dot com>, this issue is more generic: > try opening the gtktreelist and move the mouse on top of the popped up window: > text strings will become fuzzy and when you move between rows the bug can be > easily reproduced. > This makes me even more certain that the widget is drawing outside of the paint loop. We need to show this bug to the maintainer of the widget. And I need to talk with them some before chasing a fix.
Created attachment 80827 [details] Same bug when scrolling horizontally some widgets I could reproduce this bug by scrolling horizontally (not vertically) a gtktextview and similar widgets.
Created attachment 80887 [details] text in gtkentry trashed as gets selected As you can see here, the text is incorrectly made "bold" when selected with both the mouse or the arrow keys + SHIFT
After some tests with latest cairo version, i noticed that you have to define to 0 DFB_RECTANGLES to have text correctly rendered. Disabling the rect filling function also fixes bug 361377 [1] and 359553 [2]. So, such bugs are not related to gdk/dfb but rather to cairo/dfb. Attilio [1] http://bugzilla.gnome.org/show_bug.cgi?id=361377 [2] http://bugzilla.gnome.org/show_bug.cgi?id=359553
Send me a email with a patch on cairo or what you had off and on in the cairo-dfb backend and I'll make sure the code is checked in that way. Also I'll add a note to these bugs so I can fix the problem one day. I though that these were off by default in cairo as you see they are still experimental.
*** Bug 359553 has been marked as a duplicate of this bug. ***
*** Bug 361377 has been marked as a duplicate of this bug. ***
The bug was in the cairo directfb backend and should be fixed in 1.2 and later versions.