Community
Participate
Working Groups
Created attachment 127887 [details] Browser flickering in action Build ID: SWT-N20090305-2000 Steps To Reproduce: 1. Embed the browser in a Canvas. 2. Launch the application with sun.awt.noerasebackground set to true. 3. Print the control now and then: it flickers. More information: It seems that Control.printWidget(in, int, GC), line 2067 causes the flickering: SetWindowPos (hwnd, hwndInsertAfter, rect1.left, ... If I replace it with this line, the flickering goes away: setRedraw(false); SetWindowPos (hwnd, hwndInsertAfter, rect1.left, ... setRedraw(true);
I cannot reproduce this problem. Which JDK are you running?
I can't see it either. We must be running a different version of something. What XP theme are you using?
I tried with 1.6.0_10, 1.5.0_12 and 1.6.0_14, and they all have the same flickering issue. I use Windows XP default Luna blue theme, but I switched to Windows classic theme with 1.6.0_10 and got the same issue. I have Windows XP Service Pack 3 on a 2GHz dual-core laptop, 2GB RAM. Graphic card is NVidia GeForce Go 7400. When I run the sample I gave you, it does not blink for every print(gc) call but I would say 30-50% of the time, which is quite noticable. Moreover, the caret does not need to be in the search field for this to happen (so caret blinking is not the culprit for the Shell to flicker). Before the "printing hack" was put in place, I had my own hack and I noticed that some of the calls made the window to flicker. I wrapped some of the calls with setRedraw(false/true) which allowed to remove those flickering. The same technique works with your hack as indicated in the bug description. If you need more information, please let me know.
I can't see putting in the setRedraw() true/false without seeing it do something. Using setRedraw() should guarantee one complete redraw when the setRedraw(true) is executed.
> I can't see putting in the setRedraw() true/false without seeing it do > something. I wonder how we can resolve this one. I hope you manage to reproduce it on some of you systems, or else you are welcome over here in France :) > Using setRedraw() should guarantee one complete redraw when the > setRedraw(true) is executed. Adding a redraw() call at the end of the "if(fixPrintWindow)" (in addition to the setRedraw(false/true)) does not make anything to flicker and probably guarantees that it is properly redrawn. Maybe if one knows a video capturing program, I could show you the flickering in action (provided it captures with a high enough frame rate I guess).
Maybe this is a matter of system speed. If it is, then we can slow it down. Simply add these lines after "SetWindowPos (hwnd, hwndInsertAfter, rect1.left...": try { Thread.sleep(100); } catch(Exception e) {} On my system, this makes the whole shell white. This is exactly the effect I get when I say it flickers, but for a longer time of course. If I add the setRedraw(false/true) calls around the setWindowPos and sleep calls, then I don't see anything unusual. -Christopher
When I run the snippet fixPrintWindow=false, so that code does not run.
If I make the code run it flickers.
Yes, the snippet was created before several improvements (223590, 267466). When we hit a condition where fixPrintWindow is true (region clip), then it does flicker.
Fixed > 20090320
Christopher, *please* make sure the code we have in the bug report is showing the problem, otherwise, it's a waste of time and your bug won't get fixed (unless we can guess at it).
> Christopher, *please* make sure the code we have in the bug report is showing > the problem My apologies, I should have checked that after your recent GC-related fixes, and adjust the code (adding a region clip in this case). Again, thanks all for your great work!
