Overlay scrollbars can't be used with wxScrolledWindow

[michalbliznak]

wxScrolledWindow's area is refreshed incorrectly (there are ugly drawing artefacts in the window) when the content is scrolled by the mouse wheel or by scrollbars. The issue can be seen in scintilla editor as well in other custom windows based on wxScrolledWindow. The same application build with wxWidgets 2.9.4 works fine. Observed at least under Ubuntu 12.04 with integrated Intel graphics, Gnome-Shell DE.

[ericj]

Do you see this in any of the wxWidgets samples? I tested the "drawing" and "stctest" sample under Mint 12 and don't see the problem.

[vadz]

Also, if you see it in 2.9.5 but not 2.9.4, then bisecting the history to find out which revision exactly introduced the problem would be much appreciated (especially as nobody else can do it for as long as we don't know how to reproduce it).

[michalbliznak]

Drawing issue in scrolled window

[michalbliznak]

I can see the issue also in "drawing" sample; see the attached screenshot. The horizontal and vertical bold lines were caused by scrolling of the canvas. I guess the issue has appeared in November.

[pcor]

I can't reproduce it either. Looking at the screenshot, it appears as if the scrollbar is being drawn on our window, instead of outside it. With the following patch, the last "gdkwindow" and "client size" outputs for each widget should match. Do they?

Index: src/gtk/window.cpp
===================================================================
--- src/gtk/window.cpp	(revision 73099)
+++ src/gtk/window.cpp	(working copy)
@@ -2830,6 +2830,7 @@
 
     if ( m_wxwindow )
     {
+        bool hasScrollbar = false;
         // if window is scrollable, account for scrollbars
         if ( GTK_IS_SCROLLED_WINDOW(m_widget) )
         {
@@ -2864,6 +2865,7 @@
                         if (gtk_adjustment_get_upper(adj) <= gtk_adjustment_get_page_size(adj))
                             continue;
                 }
+                hasScrollbar = true;
 
                 GtkRequisition req;
 #ifdef __WXGTK3__
@@ -2902,6 +2904,8 @@
             w = 0;
         if (h < 0)
             h = 0;
+        if (hasScrollbar)
+            fprintf(stderr, "%p client size %d %d\n", m_wxwindow, w, h);
     }
 
     if (width) *width = w;
Index: src/gtk/win_gtk.cpp
===================================================================
--- src/gtk/win_gtk.cpp	(revision 73099)
+++ src/gtk/win_gtk.cpp	(working copy)
@@ -83,6 +83,8 @@
         if (x != old_x || y != old_y ||
             w != gdk_window_get_width(window) || h != gdk_window_get_height(window))
         {
+            if (w != gdk_window_get_width(window) || h != gdk_window_get_height(window))
+                fprintf(stderr, "%p gdkwindow %d %d\n", widget, w, h);
             gdk_window_move_resize(window, x, y, w, h);
 
             if (border.left + border.right + border.top + border.bottom)
@@ -140,6 +142,8 @@
         if (h < 0) h = 0;
         gdk_window_move_resize(gtk_widget_get_window(widget), x, y, w, h);
     }
+    GdkWindow* window = gtk_widget_get_window(widget);
+    fprintf(stderr, "%p gdkwindow %d %d\n", widget, gdk_window_get_width(window), gdk_window_get_height(window));
 }
 
 static void pizza_show(GtkWidget* widget)

[michalbliznak]

Here is output logged just after drawing sample start (without any interaction):

0x9900db8 client size 20 17
0x9900db8 client size 17 17
0x9900db8 client size 17 17
0x9900db8 client size 545 790
0x9900db8 client size 545 790
0x9900db8 client size 545 790
0x9900db8 client size 545 790
0x9900db8 client size 545 790
0x9900db8 client size 545 790
0x9900db8 client size 545 790
0x9900db8 client size 545 790
0x9900db8 client size 545 790
0x9900cb0 gdkwindow 548 793
0x9900db8 gdkwindow 548 793
0x9900d60 gdkwindow 548 20
0x9900cb0 gdkwindow 548 706
0x9900db8 client size 545 703
0x9900db8 client size 545 703
0x9900db8 client size 545 703
0x9900db8 client size 545 703
0x9900db8 client size 545 703
0x9900db8 client size 545 703
0x9900db8 client size 545 703
0x9900db8 gdkwindow 548 706
0x9900db8 client size 545 703
0x9900db8 client size 545 703
0x9900db8 client size 545 703
0x9900db8 client size 545 703
0x9900db8 client size 545 703
0x9900db8 client size 545 703

[pcor]

So the sizes don't match. It really looks like the scrollbars are being drawn onto our GdkWindow. I can't believe it. Lets try another test. Can you post a screenshot of the minimal sample with the following changes?

Index: samples/minimal/minimal.cpp
===================================================================
--- samples/minimal/minimal.cpp	(revision 73126)
+++ samples/minimal/minimal.cpp	(working copy)
@@ -127,6 +127,11 @@
     // create the main application window
     MyFrame *frame = new MyFrame("Minimal wxWidgets App");
 
+    wxWindow* w = new wxWindow(frame, -1, wxDefaultPosition, wxDefaultSize, wxBORDER_SIMPLE|wxHSCROLL|wxVSCROLL);
+    w->SetScrollbar(wxHORIZONTAL, 0, 10, 100);
+    w->SetScrollbar(wxVERTICAL, 0, 10, 100);
+    w->SetBackgroundColour(*wxWHITE);
+
     // and show it (the frames, unlike simple controls, are not shown when
     // created initially)
     frame->Show(true);

[michalbliznak]

Patched minimal sample

[pcor]

I bet it's their "overlay scrollbar". Does the problem go away if you run with environment variable LIBOVERLAY_SCROLLBAR set to 0? For example,

LIBOVERLAY_SCROLLBAR=0 ./drawing

[michalbliznak]

Yes, it solves the problem. The drawing issue has disappeared after switching off the overlay scrollbars as you suggested.

[PC]

(In [73136]) disable Ubuntu "overlay scrollbar", see #14871

[ericj]

I think it would be still interesting to know, why it worked with 2.9.4. Could be related to the changes that were made in #72939 or #73019

[vadz]

Yes, I'm almost sure it must have been r72939. But I didn't have time to look at why would it break it... Could someone please test that reverting it fixes the problem?

[pcor]

Hmm, I got the source code for the overlay scrollbar and got it working on my Fedora 17 system, and I don't see any problem. There must be more to it than just the overlay scrollbar.

[vadz]

I do see the problem with Unity under Ubuntu 12.04 but reverting r72939 does not fix it. So we need to run a real bisection to find out when this broke, perhaps it can give us some clues... Any volunteers?

As much as I dislike the overlay scrollbars personally, not using them makes wxWidgets applications look very differently from the native ones and this is not a good thing so it would be nice to fix this.

[pcor]

Replying to vadz:

As much as I dislike the overlay scrollbars personally, not using them makes wxWidgets applications look very differently from the native ones and this is not a good thing so it would be nice to fix this.

It's not that bad. It merely puts us in such fine company as Firefox and eclipse, which, along with a dozen or so other apps, are blacklisted by the overlay scrollbar code itself.

[vadz]

Replying to pcor:

Replying to vadz:

As much as I dislike the overlay scrollbars personally, not using them makes wxWidgets applications look very differently from the native ones and this is not a good thing so it would be nice to fix this.

It's not that bad. It merely puts us in such fine company as Firefox and eclipse

Neither are really shiny examples of native-looking UIs... wxWidgets main claim to fame is providing native LNF, we really should do better than this.

[dghart]

Replying to vadz:

I do see the problem with Unity under Ubuntu 12.04 but reverting r72939 does not fix it. So we need to run a real bisection to find out when this broke, perhaps it can give us some clues... Any volunteers?

It turned out to be r72957.

BTW this seems to be a ubuntu 12.04 (precise) issue; I can't make it happen on 12.10 (quantal).

[pcor]

Replying to dghart:

It turned out to be r72957.

BTW this seems to be a ubuntu 12.04 (precise) issue; I can't make it happen on 12.10 (quantal).

Ah hah. Thanks, this gave me enough info to find the problem. The 12.04 overlay scrollbar code is significantly different than the 12.10 code I had looked at and tested. The 12.04 code has lots of fingers stuck in the GTK pie, and it changes the GtkScrolledWindow "scrollbar-spacing" in such a way that we can't find out what it really is, so our client size calculation is wrong. The wxGTK2 wxDC::Clear() uses the client size to define the area it clears, so it's leaving an un-cleared strip which is later scrolled inward from the edge.

I can't think of any way to solve the client size problem, but I'm going to make a change which should fix wxDC::Clear() not clearing the whole client area.

[PC]

(In [73185]) Get DC size from GDK window if possible, client size can unfortunately be wrong
This should fix wxDC::Clear() not clearing the whole window on Ubuntu 12.04 with overlay scrollbars
see #14871

[dghart]

I confirm that 'drawing' now displays properly both on 12.04 and 12.10.

[vadz]

Great, thanks Paul!

Can the problem be still seen elsewhere (the original bug report mentioned wxSTC too)?

[michalbliznak]

The problem can be still seen if wxBufferedPaintDC is used for drawing. wxPaintDC and wxAutoBufferedPaintDC work fine.

[PC]

(In [73231]) Use client size determined by size-allocate when possible

Our client size calculation can be wrong for reasons beyond our control,
notably on Ubuntu 12.04 with overlay scrollbars where the GtkScrolledWindow
"scrollbar-spacing" is wrong. By using the true size from size-allocate
when it becomes available, we can recover from an earlier incorrect client
size calculation. See #14871

[AlecR]

Does this relate to 14900 at all? Seen on Ubuntu 12.04, but reported to apply to (at least) MSW as well.

[pcor]

I think this is now fixed by r73231

[bartonc]

Replying to dghart:

Replying to vadz:

I do see the problem with Unity under Ubuntu 12.04 but reverting r72939 does not fix it. So we need to run a real bisection to find out when this broke, perhaps it can give us some clues... Any volunteers?

It turned out to be r72957.

BTW this seems to be a ubuntu 12.04 (precise) issue; I can't make it happen on 12.10 (quantal).

'twas always broken, since unity's inception:
http://trac.wxwidgets.org/ticket/13229