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 662527 - Focus and state changes cause redraws on unaffected widgets
Focus and state changes cause redraws on unaffected widgets
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2011-10-23 14:30 UTC by Sandro Mani
Modified: 2012-10-16 02:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Testcases (1.13 KB, application/x-tar)
2011-10-23 14:30 UTC, Sandro Mani
Details

Description Sandro Mani 2011-10-23 14:30:04 UTC
Created attachment 199761 [details]
Testcases

I noticed that when the focused widget or the state of a widget change, other widgets receive many redraw signals.
Consider for instance the attached test application, consisting of a window with a GtkBox, a GtkToolbar and a GtkCanvas. Default focus is on a GtkToolButton. There are Gtk2 and Gtk3 variants, test_gtk2.py and test_gtk3.py.

Observations, using test_gtk3.py:
- A button-press on the window border (which causes the focused ToolButton to unfocus) causes the drawingarea to redraw three times.
- Setting window.set_focus(None) stops the drawingarea from getting redrawn in the above described situation.
- A mouse-leave on a non-focused GtkToolButton causes the drawingarea to redraw 4 times.
- In general, each focus change and each state change causes 4 redraws for any widget which is a parent of the focus-changed/state-changed widget.

Observations, using test_gtk2.py
- The drawingarea never gets redrawn on toolbutton focus / state changes
- In general, each focus change and each state change causes just 1 redraw for any widget which is a parent of the focus-changed/state-changed widget.

Using gtk3-3.2.1-1.fc16.x86_64
Comment 1 Benjamin Otte (Company) 2012-10-04 11:10:57 UTC
I can't make that happen anymore with GTK 3.4 or GTK 3.6. The behavior of GTK 3 seems to be equivalent to GTK 2 in the cases you gave.

Does it still happen for you with an updated GTK? Or can we close this bug?
Comment 2 Matthias Clasen 2012-10-16 02:11:52 UTC
Lets assume it is fixed.