wxStyledTextCtrl: Annoying flicker in wxGTK since r72578

[dghart]

As predicted, the r72578 painting fix causes an unpleasant amount of flicker, for example when typing. This can be seen in the stc sample, but it's worse in a 'real' app. It doesn't happen with wxMSW, or in SciTE.

The problem seems to be that GetClientRectangle() returns a rect that's too large by 3 or 4 pixels, which causes paintState to be paintAbandoned too often. This can be shown, and the flicker cured, by the attached patch.

I suspect this is associated with, and perhaps caused by, the change in appearance that started in wxGTK-2.9.0. As you can see in the attached screenshot, which shows a 2.8 stc on top of a 2.9 one, there's now a thin extra 'border' just inside the scrollbars. I don't know why this happens, but it looks about the correct size.

After discovering this 'fix', I then saw the new comment in r12704. I confirm that the r12704 fix works for me too, and is less hackish. I hope one or the other will be applied before wx2.9.5 is released, but clearly a solution the underlying problem would be preferable.

[jens]

It must be #12704 .

Jens

[pcor]

The change in appearance is due to r58294. We have apparently been calculating the client size of a window with scrollbars incorrectly since then because GtkScrolledWindowClass.scrollbar_spacing is, at least sometimes, invalid. I have fixed this in r72957. Does it fix this problem?

[dghart]

Replying to pcor:

The change in appearance is due to r58294. We have apparently been calculating the client size of a window with scrollbars incorrectly since then because GtkScrolledWindowClass.scrollbar_spacing is, at least sometimes, invalid. I have fixed this in r72957. Does it fix this problem?

Thank you for your very quick response!
It does fix the worst problem: in the stctest typing has stopped flickered, as the clientsize and painted rect are now the same. BTW for me gtk_widget_style_get() returned a spacing of 3, which explains the success of my hack. However it reduces the client width rather than expanding the painted width, so the extra 'border' remains (not a major issue, of course).

Unfortunately it doesn't fix the other problem: wxStyledTextCtrl::BraceHighlight still causes flickering. This can't be demonstrated in the sample as that only tries to match adjacent braces; but it's very obvious in an IDE when the cursor moves to the line of e.g. an opening or closing brace of a function.

The #12704 patch does cure this.

[arondobos]

I tested this updated SVN revision on Fedora 16. The flickering is much improved, but is not completely resolved - I still get a small amount of flicker. As dghart mentions, for brace highlighting, this fix is not sufficient unfortunately.

[dghart]

I've added a patch to the stc sample that implements 'real-time' brace matching. Flicker is now very obvious if you click on braces that span more than 2 lines, and then when clicking outside again.

[VZ]

(In [73001]) Use wxBufferedPaintDC for wxStyledTextCtrl drawing in wxGTK.

GTK+ doesn't seem to use double buffering for Scintilla window for some
reason, resulting in bad flicker when it's updated, e.g. when the user types
into it.

Force the use of double buffering at wxWidgets level by using
wxBufferedPaintDC for painting it. This may be inefficient if GTK+ does double
buffer it in some cases but at least it gets rid of the flicker.

Closes #12704, #14828.