Community
Participate
Working Groups
Created attachment 287107 [details] screenshot Version: 2021-09 (4.21) --- RC1 Build id: I20210825-1800 The attached screen shot shows the result of moving the mouse-up cursor from the right hand editor tab (OCL-2.5.oclstdlib) directly to the left adjacent tab (BooleanOption.java). As soon as the tab loses focus the editor tab is corrupted as shown. When first observed, the source tab just blanked. Once I shrank the screen to give a smaller PNG the behaviour changed to partially rather than fully blank the tab. The problem does not occur if the mouse is moved down, across then up. Only direct across. Problem reproduces with a variety of editors and with only a small number open - not dependent on the overflow area. Problem does not reproduce on 2021-06.
Most likely regression from bug 575553 or bug 501491. I can't reproduce on Linux, but not sure if I do the right thing. Could you attach a screen recording showing how do you exactly move the mouse etc?
Sorry screen recording is not in my bag of tricks. It's really simple. I did it many times. Click on right most sheet tab so that it has focus, then just move the mouse left. As soon as focus changes to the left adjacent tab, adjacent tab hover appears, adjacent tab close icon is drawn and corruption occurs. Once I did this slowly enough, I could see that it happens in the pixel or two before you get to the close icon, so it's nothing to do with the close action/hover. I tried a few variations since it initially involved a compare editor for which too many magic things happen. The consistent theme was direct movement from rightmost tab to left adjacent tab. Indirect movement and it doesn't reproduce, other tabs don't show same corruption. Different editors seem to make no difference. It even reproduced in the reopened workspace when I eventually got to restart Eclipse after a Windows Restore to remove LibreOffice 7.2 that kept hanging Windows. Just possible that the bad LibreOffice caused a crash that put something bad in my Workspace, but since you have a regression in mind, LibreOffice 7.2 is probably a red herring.
(In reply to Andrey Loskutov from comment #1) > Most likely regression from bug 575553 or bug 501491. > I can't reproduce on Linux, but not sure if I do the right thing. or bug 574641 - i remember there where less (too less?) calls upon a hover.
This happens consistently in the 'classic' theme, in the 'light' theme I do not see this behavior. In my case, the left most tab completely disappears. When continue to moving to the left, for other tabs I see that the text shifts up 1 or 2 pixels when entering the other tab. This also happens going left to right. Entering from top or bottom does not cause paint issues. I wonder if this would also be related to the old Bug 574653, in which tabs also disappeared.
It should be Bug 428697, which is about the disappearing tabs.
Just triggered it on the second last tab too. 1. select the second-last tab. 2. move mouse up or down at the border between the selected tab and the tab right of it, on the tail of the rounded tab, from outside the tab bar. 3. the second-last tab disappears. I also see artifacts that the label draws over the tail of the rounded tabs. This artifact seems to be 2-3 pixels, but sometimes it is a bigger rectangle.
(In reply to Rolf Theunissen from comment #5) > It should be Bug 428697, which is about the disappearing tabs. But that was in 4.17, and Ed says: (In reply to Ed Willink from comment #0) > Problem does not reproduce on 2021-06.
i can reproduce it - in "classic" theme only (never used that before).
I can also reproduce it without the recent changes. - in classic
(In reply to Andrey Loskutov from comment #7) > But that was in 4.17, and Ed says: > > (In reply to Ed Willink from comment #0) > > Problem does not reproduce on 2021-06. Maybe I didn't try hard enough. Maybe it's subtler than I first reported. Anyway you've clearly got a handle on some repros.
(In reply to Andrey Loskutov from comment #7) > (In reply to Rolf Theunissen from comment #5) > > It should be Bug 428697, which is about the disappearing tabs. > > But that was in 4.17, and Ed says: > > (In reply to Ed Willink from comment #0) > > Problem does not reproduce on 2021-06. The problem doesn't reproduce in 4.20, however, the root cause is similar. The classic theme uses the default CTabFolderRenderer, the other themes use the CTabFolder renderer. Bug 428697 solves the clipping issues for the CTabFolder renderer. When a similar fix is applied to the CTabFolderRenderer, the tabs do not disappear anymore. Still there seem to be some pixel offsets when going over the tabs. It seems that somewhere the GC is not well reset to the old state. (That we have seen in drawing the close button too).
(In reply to Rolf Theunissen from comment #11) > (In reply to Andrey Loskutov from comment #7) > > (In reply to Rolf Theunissen from comment #5) > > > It should be Bug 428697, which is about the disappearing tabs. > > > > But that was in 4.17, and Ed says: > > > > (In reply to Ed Willink from comment #0) > > > Problem does not reproduce on 2021-06. > > The problem doesn't reproduce in 4.20, however, the root cause is similar. You haven't bisected, which change broke the theme? > The classic theme uses the default CTabFolderRenderer, the other themes use > the CTabFolder renderer. Not sure I see the difference :-) > Bug 428697 solves the clipping issues for the > CTabFolder renderer. When a similar fix is applied to the > CTabFolderRenderer, the tabs do not disappear anymore. Would you provide gerrit? > Still there seem to be some pixel offsets when going over the tabs. It seems > that somewhere the GC is not well reset to the old state. (That we have seen > in drawing the close button too). That can be a later fix.
I got to learn to type... Its the CTabRendering (which extends CTabFolderRenderer) that is used by most themes. I haven't had time yet to bisect the issue. The change I tried is removing the clipping all together, which does to the trick, but seems quite a big hack now I look at it again. There seems to be a root cause behind it, something very odd is going on with the clipping region on SWT win32. E.g. in drawbackground, the clipping is stored and in the end restored, however, after the restore the clipping rectangle is not equal to the original one. Not drawing the cross resolves the issue too, seems that the clipping region that is provided when on the cross is incorrect.
The regression is triggered by change f902ddb0221245316c5913c4dde317f52c453770, to correct drawing artifacts of the hot close button, Bug 575398 Comment 3, to fine tune Bug 575563. This change tries to work-around an issue with line caps that are not drawn correctly under Windows. The change enables anti-aliasing on the GC, which causes the system to switch to advance graphic subsysbem. Under the advanced subsystem with anti-aliasing, the line caps are more consistent. However the switch to the advanced subsystem, triggers the clipping errors, that cause the regression we see here. These clipping errors can also be triggered by forcing the advanced system, i.e. calling gc.setAdvanced(true). My suggestion is to revert f902ddb0221245316c5913c4dde317f52c453770, and instead select round or square line caps that do not have the issue (only flat caps have the issue). Furthermore, two new bugs must be opened on SWT: 1. The line cap issues with (default) flat style (and 2px), for normal subsystem and advanced system 2. The clipping issues on the advanced subsystem, which are the root cause of this regression and also Bug 428697 were also the advance subsystem is activated.
Just an observation - if themes are disabled in prefs this doesn't happen. I see it only on the Classic theme.
(In reply to Phil Beauvoir from comment #15) > Just an observation - if themes are disabled in prefs this doesn't happen. I > see it only on the Classic theme. Contrarily, I see the issue with theming disabled too. So I see it in no-theme and classic-theme.
(In reply to Rolf Theunissen from comment #16) > (In reply to Phil Beauvoir from comment #15) > > Just an observation - if themes are disabled in prefs this doesn't happen. I > > see it only on the Classic theme. > > Contrarily, I see the issue with theming disabled too. So I see it in > no-theme and classic-theme. I have no idea why I wrote that, when what I meant to say was: Just an observation - if themes are disabled in prefs this also happens. If themes are enabled I see it only on the Classic theme.
(In reply to Rolf Theunissen from comment #14) > My suggestion is to revert f902ddb0221245316c5913c4dde317f52c453770, and > instead select round or square line caps that do not have the issue (only > flat caps have the issue). Furthermore, two new bugs must be opened on SWT: > 1. The line cap issues with (default) flat style (and 2px), for normal > subsystem and advanced system > 2. The clipping issues on the advanced subsystem, which are the root cause > of this regression and also Bug 428697 were also the advance subsystem is > activated. Rolf, do you plan to proceed? Or do should it be done by Thomas as that was the part done for the bug 575398?
(In reply to Andrey Loskutov from comment #18) > Rolf, do you plan to proceed? > Or do should it be done by Thomas as that was the part done for the bug > 575398? I need to balance my free/spare time so cannot give hard guarantees, will see if I can free up some time in the near future. Especially related to the underling SWT bugs, I feel a bit annoyed that I can report those bugs but chances are high that they get auto-closed 'wontfix' because of a leak of focus on the Windows Platform Support. I have analyzed (major/critical) bugs before, but there no follow-up. Is there even an official supporter for the Windows platform?
If the problem is triggered by by setting gc.setAntialias(SWT.ON); why not store it's value and set it back to the original value after?
(In reply to Phil Beauvoir from comment #20) > If the problem is triggered by by setting gc.setAntialias(SWT.ON); why not > store it's value and set it back to the original value after? The problem is with the GDI subsystem, which is used after setAntialias, just setting it off will not return to the default subsystem, that requires a setAdvanced(false). Doing that call is tricky, as it can mess up other renderers, like the CTabRendering which needs the advanced GDI subsystem too. Moreover, my suggestion in comment 14 is less complex overall.
(In reply to Rolf Theunissen from comment #14) > My suggestion is to revert f902ddb0221245316c5913c4dde317f52c453770 Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/185827 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=ca678760dc2d0d528e780bf92d7c1acd5457daf5 > instead select round or square line caps that do not have the issue (only > flat caps have the issue). Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/185829 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=e229551e8c42af39578a43961869249936d9fce9 > Furthermore, two new bugs must be opened on SWT: > 1. The line cap issues with (default) flat style (and 2px), for normal > subsystem and advanced system See Bug 576270 > 2. The clipping issues on the advanced subsystem, which are the root cause > of this regression and also Bug 428697 were also the advance subsystem is > activated. See Bug 576271
*** Bug 578286 has been marked as a duplicate of this bug. ***
