wxDataViewCtrl slow to (re)draw in wxWidgets 3.3.0 compared to 3.2.6 (Issue #25025)
Simon Judd
Description
Bug description:
Some time between wxWidgets 3.2.6 and 3.3.0, something changed in wxDataViewCtrl that causes it to redraw much slower, introducing a 'lag' when scrolling the list with the mousewheel or keyboard. This happens in wxMSW only as far as I can tell (which I think uses the generic wxDataViewCtrl implementation).
I'm wondering if this could be related to #23585?
Expected vs observed behaviour:
I've tried to record the difference using the snipping tool, rapidly scrolling the mousewheel up and down, hopefully it shows the issue clearly enough:
wxWidgets 3.2.6:
https://github.com/user-attachments/assets/43bb6370-3e5d-4f53-9ff4-095d68904931
and wxWidgets 3.3.0:
https://github.com/user-attachments/assets/835cab29-a9dc-4828-8bbd-e09d3efdc1b3
Stack trace:
N/A
Patch or snippet allowing to reproduce the problem:
N/A
To Reproduce:
Rapidly scroll the mousewheel within a wxDataViewCtrl (see the videos posted above)
Platform and version information
- wxWidgets version you use: 3.3.0
- wxWidgets port you use: wxMSW
- OS and its version: Windows 11
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
It could be indeed due to using composite windows by default now, in which case setting wx_msw_window_no_composited environment variable to 1 should "fix" it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Simon Judd
Hmm, unless I'm doing something wrong, setting that environment variable has no effect unfortunately.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Do you see the problem in the dataview sample too? I've tried scrolling the list control on its second page and while it's not very smooth, it doesn't seem too bad neither...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Simon Judd
Oh that's interesting - wx_msw_window_no_composited seems to affect the dataview sample (it lags if set to 0, is fine if set to 1), however the variable has no effect on the dataview in my application, it lags no matter what.
I'll have a play around tomorrow and see if I can find what might be causing it, unlike the sample my dataview is embedded within a wxAUI tab, also within a customised wxSplitterWindow, could be one of those.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Simon Judd
Unfortunately no luck - the dataview just seems to lag no matter what, I'm a bit stumped as to what could be causing it if it isn't related to the composite windows issue.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Simon Judd
sirjuddington left a comment (wxWidgets/wxWidgets#25025)Ok so a bit of an update on this one, it seems now I can 'fix' this issue by calling MSWDisableComposited() in the constructor for the data view (previously this didn't seem to have an effect, but works now after I updated wxWidgets to the latest commit). However it's not really ideal as calling it causes the list and various controls around it to flicker on redraw, I'm guessing due to lack of double buffering.
I also noticed that having a wxGLCanvas showing in the window at all causes flicker too, I guess due to #23112? So even if the data view didn't have this issue, I'd be getting the flickering anyway as I'm using wxGLCanvas for many things.
Is there any way to revert the behaviour completely to what it was pre-3.3.0? Everything was working perfectly fine before :(
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25025)Reverting the use of WS_EX_COMPOSITED would be a huge change and would mean losing automatic double-buffering, i.e. result in more flicker when the application doesn't do it on its own.
But I do realize that it introduces a load of problems that I had no idea about when we started using it, unfortunately. I am not sure what to do here, but if we really want to revert it, it should probably be done right now, before 3.3.0...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Simon Judd
sirjuddington left a comment (wxWidgets/wxWidgets#25025)Hmm if it's a large undertaking to revert it I can probably live with it, I've since noticed the main culprit for flickering (apart from the wxDataViewCtrl itself) are my custom drawn toolbars, so maybe there is something else going on there (they could probably just be replaced with wxAuiToolbars and a custom art provider tbh)
I guess the question is how much this will affect other apps that use wxGlCanvas/wxDataViewCtrl, as mine is fairly niche so it might not be a problem in most cases
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
PBfordev left a comment (wxWidgets/wxWidgets#25025)Just curious: So setting wx_msw_window_no_composited to 1 prior to starting an application will not result in the exactly same behaviour as in 3.2?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
PBfordev left a comment (wxWidgets/wxWidgets#25025)Just curious: So setting
wx_msw_window_no_compositedto1prior to starting an application will not result in the exactly same behaviour as in 3.2?
To answer my own question, after a bit of digging. There could be at least one noticeable adverse effect of setting wx_msw_window_no_composited to 1. wxAutoBufferedPaintDC will not be buffered anymore, because at compile-time we have this
// All current ports use double buffering. #define wxALWAYS_NATIVE_DOUBLE_BUFFER 1 ... #if wxALWAYS_NATIVE_DOUBLE_BUFFER #define wxAutoBufferedPaintDCBase wxPaintDC #else #define wxAutoBufferedPaintDCBase wxBufferedPaintDC #endif class WXDLLIMPEXP_CORE wxAutoBufferedPaintDC : public wxAutoBufferedPaintDCBase
and the native composition (WS_EX_COMPOSITED) was turned off at run-time.
wxAutoBufferedDC is used also in wxWidgets own code, only MSW wxComboCtrl uses function wxAutoBufferedPaintDCFactory(wxWindow*), which returns either wxPaintDC or wxBufferedPaintDC depending on whether the window is double buffered or not.
This could result in flickering in wxDataViewControl, wxGrid, wxRibbon, wxStyledTextControl, and others
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25025)I think we're finally going to revert the use of WS_EX_COMPOSITE, see #25663, which should fix this too.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25025)Please check that #25808 fixes this if you can.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Simon Judd
sirjuddington left a comment (wxWidgets/wxWidgets#25025)That branch does indeed fix the issue, however I still need to call MSWDisableComposited() otherwise the slow scrolling issue remains. It does fix the flickering though, so as long as I call that everything is fine.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25025)Thanks for testing but it's completely unexpected that you need to call MSWDisableComposited() as it's disabled by default in this PR and so this function shouldn't do anything. Please check that you haven't mixed up old and new sources somehow because I just can't see how it can happen.
If you still see different behaviour with and without calling this function, please check (e.g. with Spy++) if your windows really have WS_EX_COMPOSITED style before/without calling it because they shouldn't.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Simon Judd
sirjuddington left a comment (wxWidgets/wxWidgets#25025)Ah ok yeah you're right, I forgot I still had SetDoubleBuffered(true) there as well which appears to be the actual culprit
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Closed #25025 as completed via b5a9fa3.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.