Community
Participate
Working Groups
From bug 511802. When changing the synchronous layout and more important the synchronous paint update to deferred layout Windows shows massive paint errors/stalled areas. The effect can be seen in video attached in bug 511802. Applying change from bug 354762 for Windows deferred layout painting errors are less sever but still intolerable worse as it is now.
Resetting target, please re-target as required.
I have a use-case on Windows that uses SWT.EMBEDDED to re-parent a hardware accelerated native window to an SWT composite. This works as expected, except that we see a lot of flickering when resizing a sash. The flickering occurs even if the sash being resized has nothing to do with the embedded composite. We don't see this problem on macosx or linux, even without the fix for bug 511802. We'd be very interested to know if anyone is working on this problem.
I already invested some time to investigate this problem, however without a good result yet. Actually I came to the observation that resizing in Eclipse works inexplicable well. After working on this I noticed many flickering (especially around scrollbars) in other applications on resize. You could almost say flickering is part of the look and feel of Windows. To answer your actual question. I had not much time for this recently but still plan to investigate this problem further.
Created attachment 281989 [details] Video capture showing flicker Thank you Paul for the reply. I'm attaching a video of a small app I use to show the flicker problem. You can see that when I resize docked views, the editor region flickers significantly. But, at the end of the video, when I resize the entire app, there is only minimal tearing on the right side. In person, the view flickers even more quickly than the video shows.
if (Platform.getOS().equals(Platform.OS_WIN32)) { host.requestLayout(); host.update(); } seems to be sufficient for Windows. I see no cheese with it, only if I remove host.update() which triggers the UI update the cheese happens.
Adding Alexandr who did fixes in SWT for GTK and Win. Alexandr, on GTK and Mac a requestLayout call is sufficient, on Windows we also need to call update();
New Gerrit change created: https://git.eclipse.org/r/163834
Created attachment 283080 [details] Flicker with proposed change (In reply to Lars Vogel from comment #5) > if (Platform.getOS().equals(Platform.OS_WIN32)) { > host.requestLayout(); > host.update(); > } > > seems to be sufficient for Windows. I see no cheese with it, only if I > remove host.update() which triggers the UI update the cheese happens. Does not work. It took me quite some time to found even the reason why the existing code works well on Windows and the setRedraw(false) is the key element. If you see no flickering you might moved the wrong border. Without setRedraw(false) and with this change I see heavy flickering. (In reply to Lars Vogel from comment #6) > Adding Alexandr who did fixes in SWT for GTK and Win. > > Alexandr, on GTK and Mac a requestLayout call is sufficient, on Windows we > also need to call update(); The update() is also necessary on GTK but it is placed in Display.runDeferredLayouts() after the layout is actually performed. That's also why a combination of requestLayout() + update() makes not much sense. It might work by accident because a resize triggers many layout requests and the update() after requestLayout is 'applied' for the finished layout from the previous resize step.
Created Bug 563712 with Gerrit to add the update call to the Display class on Windows.
Created attachment 283081 [details] Screencast Thanks Paul for the help. Attached you see how my windows behaves without the setRedraw calls. Looks ok to me, for a very short time cheese is visible but this is the same in my host Eclipse.
Ah, I think I looked at the wrong place. The flickering is on the right hand side of the editor?
(In reply to Lars Vogel from comment #11) > Ah, I think I looked at the wrong place. The flickering is on the right hand > side of the editor? Correctly. In the current version the scrollbar is rock solid but the change make it jump back and forth. Here is a great Stackoverflow post which explains various resize problems on Windows and judges this result as the worst (where I would agree). https://stackoverflow.com/a/53032800 > This looks horrible, terrible, abysmal, disgusting, ... there are not even words to > describe how bad this looks. > The human eye is extremely sensitive to motion, even motion that happens over just a > few frames of time. Our eye instantly picks up on this bizarre back-and-forth motion > of R and we immediately know something is seriously wrong. > So here you can begin to get a sense of why some of these ugly resize problems only > happen when you drag the left (or top) border and not the right (or bottom) border. > In reality, both cases (Figure 1c3-2 vs. Figure 1c3-3) do something weird. In Figure > 1c3-2 we temporarily add some background pixels B that do not belong there. But this > weird behavior is much less noticeable than the back-and-forth motion of Figure 1c3-3. > This back-and-forth motion is the jitter/flicker/jumping that so many StackOverflow > questions are about.
(In reply to Lars Vogel from comment #11) > Ah, I think I looked at the wrong place. The flickering is on the right hand > side of the editor? Correctly. In the current version the scrollbar is rock solid but the change make it jump back and forth. Here is a great Stackoverflow post which explains various resize problems on Windows and judges this result as the worst (where I would agree). https://stackoverflow.com/a/53032800 > This looks horrible, terrible, abysmal, disgusting, ... there are not even > words to describe how bad this looks. > The human eye is extremely sensitive to motion, even motion that happens > over just a few frames of time. Our eye instantly picks up on this bizarre > back-and-forth motion of R and we immediately know something is seriously > wrong. > So here you can begin to get a sense of why some of these ugly resize > problems only happen when you drag the left (or top) border and not the > right (or bottom) border. > In reality, both cases (Figure 1c3-2 vs. Figure 1c3-3) do something weird. > In Figure 1c3-2 we temporarily add some background pixels B that do not > belong there. But this weird behavior is much less noticeable than the > back-and-forth motion of Figure 1c3-3. > This back-and-forth motion is the jitter/flicker/jumping that so many > StackOverflow questions are about.
Thanks Paul, I still see some cheese / jumping of the scrollbar in the current version without the patch. I added again the reDraw call but using requestLayout (with an update call which makes in sync again). Looks the same for me but you are more sensitive here, please give it a try. Once / if Bug 563712 gets fixed, we can remove the update call and should have real async layout. It may also make the reDraw call obsolete, if the layout is done async.
Had tried that before. Does not work. The main problem for all those attempts is that requestLayout does nothing by itself and the setRedraw has to be around the actual layout to suppress the wrong intermediate drawings. Or, of cause, fix the wrong drawings what I have tried but not yet succeeded.
I didn't really study this topic and only had a glance. What I noticed is that every `Composite.resizeChildren()` calls its own `DeferWindowPos()`. THis doesn't sound too good, I would expect a significant improvement if everything happened under a single `DeferWindowPos()`. @Paul would you like to give it a try?
Paul, are you still planning to look at this issue?
Moving out of 4.18, please re-target as required.
Ping! Is this still in plan for 4.19 ?
Resetting the target for now.
