Community
Participate
Working Groups
Build Identifier: 20201210-1552 Eclipse hangs often when I move the mouse over the tree in the Outline view or when I click on it. CPU load spikes and Windows reports Eclipse as "not responding". The common stack trace in every case is: at org.eclipse.swt.widgets.Tree.wmNotify(Tree.java:7226) at org.eclipse.swt.widgets.Control.WM_NOTIFY(Control.java:5384) Often, the method called is org.eclipse.swt.widgets.Tree.wmNotifyToolTip(Tree.java:7976) My guess is that wmNotify() somehow triggers an event which causes Windows to call WM_NOTIFY again. This is happening for maybe two weeks. I'm not aware that I changed anything in Eclipse since December. In the Windows 10 update history, I see this: Feature update to Windows 10, version 1909 (2) Successfully installed on 29/01/2020 Eclipse installation history says that I updated to Platform 4.18 on January, 15th. Reproducible: Sometimes Steps to Reproduce: Moved the mouse to the icons in the top right corner or click on an item in the Outline view. I haven't seen this in the Package Explorer but then, I'm using "Open Type" a lot. It's not happening all the time but today, it hung ~5 times today.
Created attachment 285555 [details] Thread Dump #1
Created attachment 285556 [details] Thread Dump #2
Created attachment 285557 [details] Thread Dump #3
Created attachment 285558 [details] Rest of the thread dumps
Restarting Eclipse or the PC didn't help. After a crash in Eclipse, I closed the Outline view and reopened it. Since then, the problem is gone... Keeping an eye on it.
I had this bug already with Eclipse 2020-06 (4.16). At that time it helped to start Eclipse with Java 8 instead of Java 11 (never had a hang with JDK 8). Today I wanted to update to Eclipse 2020-12 (4.18), which does not accept Java 8 as Startup-VM (Option -vm) anymore. Now the bug is again there. Since it constantly happens in a class of my main interrest, I'll have to downgrade again... It seems to me, that it appears only for certain classes, and that method signatures play a role. Following, I post a sample class that definitely produces the hang, when you click/hover over the outline. At least in my installation ;-) ============ BEGIN OF SOURCE ============ package test.outline; import java.util.*; import javax.swing.colorchooser.AbstractColorChooserPanel; public class TestOutline { AbstractColorChooserPanel determineVolumeCalculationStrategy( Collection<Object> c1, Collection<Object> c2) { return null; } AbstractColorChooserPanel runCalculation(Collection<Object> c1, Collection<Object> c2) { return null; } Object createBinPacker(AbstractColorChooserPanel s, Collection<Object> c) { return null; } } ============ END OF SOURCE ============
(In reply to Detlef Keil from comment #6) > I had this bug already with Eclipse 2020-06 (4.16). Note that bugs will not be fixed if they are not even know to the community, still not said that they will get soon fixed though. > It seems to me, that it appears only for certain classes, and that method > signatures play a role. Following, I post a sample class that definitely > produces the hang, when you click/hover over the outline. At least in my > installation ;-) I cannot reproduce it locally. Just wondering, you say it happens in certain classes. Could it be related to having imports of javax? That could explain the difference between Java 8 and 11.
Created attachment 285597 [details] Test workspace to reproduce problem with the Eclipse 4.18 SDK Zipped test workspace to reproduce the problem with the Eclipse 4.18 SDK (as downlaodable from https://download.eclipse.org/eclipse/downloads/drops4/R-4.18-202012021800/).
(In reply to Rolf Theunissen from comment #7) > Note that bugs will not be fixed if they are not even know to the community, > still not said that they will get soon fixed though. You are definitely right. (And I hate it myself, if I don't get feedback for my software, too.) But since I used first time a Java version not publisched by ORACLE (or formerly SUN), I blamed it on the JDK at that time. (BTW: It was AdoptOpenJDK 11.0.7.+10 then.) > I cannot reproduce it locally. Just wondering, you say it happens in certain > classes. Today I downloaded the Eclipse 4.18 SDK for 64 bit Windows from https://download.eclipse.org/eclipse/downloads/drops4/R-4.18-202012021800/ to reproduce the problem on a new workspace with a "clean" Eclipse distribution and I couldn't reproduce it right away. Then I used my own workspace and had again the same hang. Now I produced and uploaded a test workspace, which definitly reproduces the hang with the Eclipse 4.18 SDK. All you have to do is: 1. Unzip the contents of the ZIP-File to C:\ (such that it will contain the workspace directory C:\EclipseWorkspaceTestOutline). 2. Start Eclipse 4.18 SDK (64 bit Windows) with a OpenJDK Java 11 version. I used the following AdoptOpenJDK hotspot Java: openjdk version "11.0.10" 2021-01-19 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.10+9) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.10+9, mixed mode) 3. Choose C:\EclipseWorkspaceTestOutline as workspace 4. When you see the test class in the editor and in the outline, just move with your mouse over the different methods in the outline. BTW: I'm running Eclipse on Windows 10 Enterprise, Version 1909, Build 18363.1377 > Could it be related to having imports of javax? That could explain > the difference between Java 8 and 11. I was wondering about that, too. But the javax import in my "productive" class, where I get the same hang, is actually an import of another abstract class of the project, which itself defines no modules. (Like in the sample project in the uploaded workspace.)
I am not able to reproduce it on a very similar environment (AdoptOpenJDK 11.0.7.+10, Windows 10 Enterprise, Version 1909, Build 18363.1316), also not with your workspace. I wonder if you might be suffering from Bug 548443. Otherwise, would any of you be able to attach a profiler (like jvisualvm [1] or Yourkit [2]) to get some real profiling data where the time is spend? [1] https://wiki.eclipse.org/How_to_report_a_deadlock#Getting_a_stack_trace_on_Windows [2] https://www.vogella.com/tutorials/EclipsePerformance/article.html#yourkit
Created attachment 285634 [details] Another hang today, again in wmNotifyToolTip I've ran jstack several times. I see org.eclipse.swt.widgets.Control.WM_NOTIFY ... org.eclipse.ui.internal.Workbench$$Lambda$203/0x0000000800dfa9c0.run in all of them.
Java version information: java.vm.compressedOopsMode=32-bit java.vm.info=mixed mode, sharing java.vm.name=Java HotSpot(TM) 64-Bit Server VM java.vm.specification.name=Java Virtual Machine Specification java.vm.specification.vendor=Oracle Corporation java.vm.specification.version=15 java.vm.vendor=Oracle Corporation java.vm.version=15.0.1+9-18 Windows has been updated since my first report: Windows 10 Pro 64bit Version 1909 OS build 18363.1316
(In reply to Aaron Digulla from comment #11) > Created attachment 285634 [details] > Another hang today, again in wmNotifyToolTip > > I've ran jstack several times. I see > > org.eclipse.swt.widgets.Control.WM_NOTIFY > ... > org.eclipse.ui.internal.Workbench$$Lambda$203/0x0000000800dfa9c0.run > > in all of them. That some method is always in the call-stack doesn't mean that the root cause is in that method. It can be that some or multiple sub-calls are slow or it can be that this method is called too often from a super-call. Please attach a proper profiling output (not 'random' samples), which shows where time is spend and how often methods are called. Otherwise the issue cannot be diagnosed properly.
Created attachment 285665 [details] CPU sample done with Java VisualVM The majority of the time is spent in Tree.wmNotify.
(In reply to Aaron Digulla from comment #14) > Created attachment 285665 [details] > CPU sample done with Java VisualVM > > The majority of the time is spent in Tree.wmNotify. Yes, it shows that most of the time is spend in Tree.wmNotify or better Tree.wmNotifyToolTip (113ms). Though it also shows that it is called 385 times. So that is 0.3ms on each iteration. Now we could try to speed up the wmNotifyToolTip, if we are really lucky and get a reduction of 50% (which seems unfeasible). Still the operation would take 65ms. If we instead try to reduce the 385 calls to 1 call (seems more feasible) we would reduce the time to below 1ms. Other possibility is that there is a slow and a fast code path, and that the slow code path is chosen too often. Next is to investigate where the huge number of wmNotifyToolTip calls come from.
The tooltips are only shown for outline entries that are wider then the view (the same is true for the package/project explorer), this might explain why you only see it on certain signatures. Would you see similar behavior on long resource names in the project explorer. Which view has focus when you observe the behavior?
I agree that 50% better performance would not help. Eclipse would just hang "faster" (i.e. use more CPU while hanging). Most of the time, the text editor has focus. This happens either when I move the mouse over the Outline View to switch the perspective. It also often happens when I click an entry on the Outline View. Most of the entries were less wide than the view (I have a big screen and I to guess names that are cut off). Also, the entries shouldn't have tooltips. I don't remember Eclipse showing any tooltips when I hover over a field or method in the Outline View. My guess would be that Eclipse thinks is should open a tooltip but that's already a bug since the name is fully visible. It then tries to open it. Since there should be no tooltip, it can't open, so it tries again. As I said, this effectively blocks the UI. Eclipse hangs and I have to kill it. I've been looking at the source code https://github.com/eclipse/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/Eclipse%20SWT/win32/org/eclipse/swt/widgets/Tree.java#L7224 I think the bug is that "hdr.hwndFrom == itemToolTipHandle" is true when it shouldn't be. This could happen when hdr.hwndFrom is 0 and we don't have a tooltip. I see != 0 checks in other places of the code. Maybe a quick fix would be to add a != 0 check plus logging a warning. Build a new SWT JAR and attach it to this issue. I can then replace the one in Eclipse and run it for a few days to see whether I get the warning.
Another bit of information: I have never seen this with the debug or package view! Not even once in all the time. It only always happens with the Outline view. I'm using the package and debug views much more often than the outline view (I prefer Ctrl+O to move around). Ctrl+O also uses a Tree widget, right? Haven't had any problem with that one either but then, the mouse is usually outside that popup. Checking whether those views configure the Tree widget differently should give us another clue why this happens.
Based on discussion in comment 17, will share a possible gerrit patch shortly.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/177354
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/177354 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=23cbb9ad332724894640251ff38f679d6bbbff83
(In reply to Eclipse Genie from comment #21) > Gerrit change > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/177354 was > merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=23cbb9ad332724894640251ff38f679d6bbbff83 Above fix can be verified on below and on-wards Eclipse IBbuild: https://download.eclipse.org/eclipse/downloads/drops4/I20210310-2050/ @digulla@hepe.com Can please confirm if this Eclipse IBuild works for you ? Thanks!
I've tested the IBuild. To replicate the problem, I've done the following: - Create a new workspace (-data C:/dev/test-workspace) - Import just one small Maven project - Make the Outline view very narrow (because of the comment that the tooltip - which you get when the text doesn't fit - might trigger the bug) - After starting Eclipse, wait until it settles (no jobs in the Progress view). Note: I have two monitors. Eclipse is running on the left screen with a font size of 100%. The right screen has a font size of 150%. I can now trigger the bug easily by just moving top to bottom over the Outline view (tried three times). I have about 20 elements in the view. Eclipse hangs near the bottom (16-18th element). I then copied all org.eclipse.swt.* JARs from the IBuild into eclipse\dropins\bug571209\. The win32 JAR is called: org.eclipse.swt.win32.win32.x86_64_3.116.100.v20210311-0208.jar But even starting with -clean, Eclipse doesn't pick these JARs up :-( I then unpacked and started the IBuild itself. Bad news: It still hangs. Buuut... now, I have two Eclipse installed. So I started one with the options to wait for remote debugging. Unfortunately, conditional breakpoints don't work anymore. When I use this: System.out.println("Test"); return false; Eclipse tells me there is a compilation error :-( I literally copied the code from the docs! Also, I never get tooltips when the breakpoints are enabled (probably since I have to switch windows to continue). When I disable all breakpoints, it doesn't hang. When I disconnect, it doesn't hang. Enabling the remote debugger seems to cure the issue. I wonder if this is a JVM bug?
I have started Eclipse under the debugger and triggered the hang. Then I connected from a second Eclipse and paused the VM in the debugger. This is the stack trace: Thread [main] (Suspended) Tree.wmNotifyToolTip(NMTTCUSTOMDRAW, long) line: 8022 Tree.wmNotifyToolTip(NMHDR, long, long) line: 7963 Tree.wmNotify(NMHDR, long, long) line: 7226 Tree(Control).WM_NOTIFY(long, long) line: 5382 Tree(Control).windowProc(long, int, long, long) line: 4816 Tree.windowProc(long, int, long, long) line: 5976 Display.windowProc(long, long, long, long) line: 4930 OS.DispatchMessage(MSG) line: not available [native method] Display.readAndDispatch() line: 3624 PartRenderingEngine$5.run() line: 1157 Realm.runWithDefault(Realm, Runnable) line: 338 PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 1046 E4Workbench.createAndRunUI(MApplicationElement) line: 155 Workbench.lambda$3(Display, WorkbenchAdvisor, int[]) line: 644 0x0000000800d2aa10.run() line: not available Realm.runWithDefault(Realm, Runnable) line: 338 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 551 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 156 IDEApplication.start(IApplicationContext) line: 152 EclipseAppHandle.run(Object) line: 203 EclipseAppLauncher.runApplication(Object) line: 134 EclipseAppLauncher.start(Object) line: 104 EclipseStarter.run(Object) line: 401 EclipseStarter.run(String[], Runnable) line: 255 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 64 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 564 Main.invokeFramework(String[], URL[]) line: 653 Main.basicRun(String[]) line: 590 Main.run(String[]) line: 1461 Main.main(String[]) line: 1434 When I step through the code using "Step over", I see this: Display.windowProc(long, long, long, long) line: 4930 Display.windowProc(long, long, long, long) line: 4929 Code in question: 4929: if (lastControl != null && lastHwnd == hwnd) { 4930: return lastControl.windowProc (hwnd, (int)msg, wParam, lParam); lastControl Tree (id=74) Tree 74 is the Outline view. I've added a breakpoint at Display.readAndDispatch() line: 3624 and Display.readAndDispatch() line: 3623. Those never trigger. So what happens is that calling Tree.windowProc() will eventually call Display.windowProc() but without adding a stack frame. That's what I meand with "infinite loop": Somehow, the code in WM_NOTIFY triggers and event and that event gets handled right away but that triggers the event again -> endless loop. msg MSG (id=201) hwnd 67530 lParam 0 message 275 time 68457515 wParam 1 x 2412 y 1061 Then I started to look at all the places where the code calls OS.SendEvent(). Tree.sendEraseItemEvent(TreeItem, NMTTCUSTOMDRAW, int, RECT) line: 4362 TreeItem.getBounds(int, boolean, boolean, boolean, boolean, boolean, long) line: 443 Tree.sendPaintItemEvent(TreeItem, NMTTCUSTOMDRAW, int, RECT) line: 4418 TreeItem.getBounds(int, boolean, boolean, boolean, boolean, boolean, long) line: 443 <--- last place before it goes back to Display.windowProc() Local variable: data GCData (id=675) alpha 255 background 16777215 backgroundPattern null device Display (id=73) focusDrawn false font Font (id=676) foreground 0 foregroundPattern null gdipBgBrush 0 gdipBrush 0 gdipFgBrush 0 gdipFont 0 gdipGraphics 0 gdipPen 0 gdipXOffset 0.0 gdipYOffset 0.0 hBrush 0 hGDIFont 0 hNullBitmap 0 hOldBrush 0 hOldPen 0 hPen 0 hwnd 0 image null layout -1 lineCap 1 lineDashes null lineDashesOffset 0.0 lineJoin 1 lineMiterLimit 10.0 lineStyle 1 lineWidth 0.0 ps null state -1 style 0 uiState 3 Stack: Display.windowProc(long, long, long, long) line: 4930 OS.SendMessage(long, int, long, long) line: not available [native method] TreeItem.getBounds(int, boolean, boolean, boolean, boolean, boolean, long) line: 443 <--- Last line above TreeItem.getBounds(int, boolean, boolean, boolean) line: 413 TreeItem.getImageBoundsInPixels(int) line: 823 TreeItem.getImageBounds(int) line: 818 TreeViewerRow.getImageBounds(int) line: 325 ViewerCell.getImageBounds() line: 344 DecoratingJavaLabelProvider(StyledCellLabelProvider).paint(Event, Object) line: 363 OwnerDrawLabelProvider$OwnerDrawListener.handleEvent(Event) line: 62 EventTable.sendEvent(Event) line: 89 Display.sendEvent(EventTable, Event) line: 4209 Tree(Widget).sendEvent(Event) line: 1043 Tree(Widget).sendEvent(int, Event, boolean) line: 1067 Tree(Widget).sendEvent(int, Event) line: 1052 Tree.sendPaintItemEvent(TreeItem, NMTTCUSTOMDRAW, int, RECT) line: 4427 Stepping through the code: Tree(Control).windowProc(long, int, long, long) line: 4859 result is null Tree(Control).windowProc(long, int, long, long) line: 4861 does nothing Parameters: hwnd 67524 msg 4360 wParam 0 lParam 0 The code in "msg" doesn't match anything in the switch() OS.CallWindowProc() at Tree.callWindowProc(long, int, long, long) line: 1542 returns 2317879734240 Again no match in the switch() Tree(Control).windowProc(long, int, long, long) line: 4864 eventually returns to Display.windowProc(long, long, long, long) line: 4930 lastControl is the Tree. Stepping into and we're at Display.windowProc(long, long, long, long) line: 4929 when it should be Tree.windowProc() -> the cycle repeats. I changed lastControl to null in the debugger. I then tried to change control to null but Eclipse won't let me. Please provide a version of SWT with debug symbols. Now the code continues with line Display:4932 but it just looks up the Tree and goes back to 4930. When I set the local variable control to null, It again runs Tree.windowProc() but only once. The next time the code hits the breakpoint at line 4930 is with lastControl == Shell. Afterwards, Eclipse works again. The variables at TreeItem.getBounds(int, boolean, boolean, boolean, boolean, boolean, long) line: 443 don't change in the loop. The rect RECT (id=803) bottom 396 left 66 right 497 top 378 is always the same. So Eclipse paints the same TreeItem over and over. During the debugging, I saw that there are two sendEvent() methods. When send is false, the event is just put into the queue. Maybe Tree.sendPaintItemEvent(TreeItem, NMTTCUSTOMDRAW, int, RECT) line: 4427 should be Widget.sendEvent (SWT.PaintItem, event, false);? I would like to try setting the parameter "send" to false but I can't without debug symbols.
While investigating a bit, I noticed some very odd behavior that might be the related to this. When I comment out in Tree.java#imageIndex() line 3677 [if (hOldImageList != hImageList)], then Eclipse starts eating 100% CPU time on one core, and the whole UI is cheesing, though the application as a whole remains kind of responsive. It seems strange that removing this optimization has this kind of huge impact. Some performance regression was expected (due to the comment above) but not a full breakdown of the WorkBench.
Created attachment 285844 [details] Test case 2: Tool Tip fully on one screen
Created attachment 285845 [details] Test case 3: Tool Tip would be about half on the right screen
Created attachment 285846 [details] Test case 4: Only a small portion of the Tool Tip is on the right screen
(In reply to Niraj Modi from comment #22) > (In reply to Eclipse Genie from comment #21) > > Gerrit change > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/177354 was > > merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=23cbb9ad332724894640251ff38f679d6bbbff83 > > Above fix can be verified on below and on-wards Eclipse IBbuild: > https://download.eclipse.org/eclipse/downloads/drops4/I20210310-2050/ (In reply to Niraj Modi from comment #22) > Above fix can be verified on below and on-wards Eclipse IBbuild: > https://download.eclipse.org/eclipse/downloads/drops4/I20210310-2050/ I have tested the build I20210310-2050, but the problem persists for me, too. However, I pricked up my ears when I read comment #23. There Aaron Digulla wrote: > Note: I have two monitors. Eclipse is running on the left screen with a font > size of 100%. The right screen has a font size of 150%. That's almost the same setting that I have! I'm running Eclipse on a Windows 10 notebook with an external monitor. The external monitor is on the left side and is configured in windows as main screen with 100% zoom. The notebook screen (right side) is configured as second screen with 125% zoom. According to Windows this setting applies to “fonts, apps, as well as other elements” (translated from German). So I restarted my example workspace that I uploaded a month ago (https://bugs.eclipse.org/bugs/attachment.cgi?id=285597), and re-tested as I wrote in comment #9 with the following cases: 1. Both screens on 100% zoom: Everything work's perfect. 2. Using the mixed setting with 100%/125% with a normal ("restored") Eclipse window such that the displayed tool tip fits totally on one of the screens. Everything is fine, too. 3. Using the mixed setting but moving the restored Eclipse window near the screen border, such that half of the tooltip should be displayed on screen 1 and the other half on screen 2. Now the hang occurs. In this case no tooltip can be seen at all. That is, Eclipse hangs before it shows up. Afterwards Eclipse cannot be used anymore and has to be stopped hard. 4. Mixed setting but only a small part of the tooltip is on screen 2. To my surprise, this worked without hangs. Thus, the hang occurs only, if at least about the half of the tooltip would be displayed on the right screen with the 125%. I uploaded screenshots for cases (2), (3), and (4), so you can better see what I mean. Maybe this explanation helps to nail down the problem. At least, now there are two workarounds to this bug that work for me and hopefully for others: - Workaround 1: Use the same zoom factor on both screens. - Workaround 2: Run Eclipse on the right screen only.
So it's probably related to two-monitor setup and the fact that there are suddenly two bounding boxes (since the font size changes) instead of one which stretches over two physical monitors. That gives us a few solutions/workarounds: 1. Set all screens to 100%. 2. Clip the tooltip at the edge of the screen. 3. Move the tooltip so it's completely inside of the monitor. If it's too wide, clip it. #1 is a good workaround until this bug is fixed. I think #3 should be strongly considered. The tooltips in trees make sense on the left side of the screen (where they usually leak into the huge text editor area) but on the right side, it's a kind of highlight effect only since the overflow will be outside the visible area if you have a single monitor setup. If we keep the tooltips inside of Eclipse's window, that would fix the issue most of the time (unless someone moves the Eclipse window until it's on both screens).
In a similar setup, I cannot reproduce the hang. However, what I see is that on the test outline, the first tooltip appears as a scaled window (125% font size) it also appears on a incorrect location. That is, the location seems to be scaled too. For me, the tooltip appears almost instantly disappears again. After that, the tooltip works properly. Not sure if it is the same implementation but, would you be able to reproduce it on a pure SWT application, like an changed Snippet125? I was not able to get similar behavior (though I did not try the tree widget yet). https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet125.java
I think I found another detail: My two monitors have a different vertical pixel size. One is 1600, the other is 1080. As I said, it usually happens near the end of the Outline view which means the tooltip on the second screen (whose position is scaled) is now outside the visible area (i.e. y == 1500 * 1.25 is way outside of 1080). I'll try with the snippet next.
Created attachment 285879 [details] Trace of notification loop Finally, I triggered the issue too. I have added log tracing to all OS.SendMessage calls and all return statements in Display.windowProc, see snippets below. After the loop was triggered, I enabled the trace/breakpoints see the attachment for the output. OS.SendMessage breakpoints: StackTraceElement[] stack = Thread.currentThread().getStackTrace(); System.out.println(stack[1]); System.out.println(stack[2]); System.out.println(stack[3]); System.out.println(stack[4]); System.out.println(stack[5]); return false; Display.windowProc return statement breakpoints: System.out.println("message: " + msg + " - control: " +lastControl + " hwnd: " + hwnd); return false;
It is a strange bug, I have multiple Eclipse instances on most of them I cannot reproduce the issue. On others (runtime instance) I can consistently trigger the issue, not only on the outline but also in the project explorer. To trigger, have two screens with different scaling, in my case left 100% right 125%. Then position the such that it is visible on both screens, and tooltips will be shown for long labels (make is narrow). When hovering on the right screen the the tooltip shows up normally. When hovering on the left screen, the whole UI enters the infinite event loop. I have no clue yet what is the difference between the different Eclipse instances. Although I do notice difference in how the instances handle resolution changes, when moving the window between the screens. All are nightlies but I see 3 kinds of behaviors: 1. Nothing happens, the window is shown on 100% on all screens 2. The window scales up, on one screen it shows 100% the other screen shows 125% and fonts look ugly, so some scaling is done here. 3. The font of the menu bar is increased (properly scaled up to 125%), however the tree labels are still shown in 100%. For the 3th behavior I can reproduce the lookup.
(In reply to Rolf Theunissen from comment #34) > Although I do notice difference in how the instances handle > resolution changes, when moving the window between the screens. All are > nightlies but I see 3 kinds of behaviors: > 1. Nothing happens, the window is shown on 100% on all screens > 2. The window scales up, on one screen it shows 100% the other screen shows > 125% and fonts look ugly, so some scaling is done here. > 3. The font of the menu bar is increased (properly scaled up to 125%), > however the tree labels are still shown in 100%. > > For the 3th behavior I can reproduce the lookup. I tried again with my two instances and I got, what you described as (2) and (3). The bug occurs only for partial scaling as you described under (3). The strange thing: One of my eclipse instances is 2020-06, which I started with Java 8 and with Java 11. In the first case (Java 8) I got behavior (2) and tool tips showed up fine at every location (left screen, right screen, and over both screens). But when I started this instance with Java 11, I got behavior (3) and I got the hangs as I described in comment #29. BTW: When I started with Java 8, the tooltips were always scaled in the same size as the main window. Furthermore, I noticed, that the scaling takes place, when the middle of the window passes the screen boarder. In my observations the hang always occurred, when the tooltip would have been more than a half on the screen scaled to 125%. I don't know much about SWT, but I did a lot Swing programming. In Swing tool tips are as well window objects. So my guess is, that the problem is caused since the tooltip "wants to be" scaled to 125%, whereas the component it relates to, is still scaled to 100%. This possibly leads to problems of size and location calculation for the tooltip, which in turn causes the hang. As said: This is just a conjecture. However, I wonder, why the different Java version affects the behavior. As far as I know, SWT uses the JAVA native interface to directly access the OS graphics routines. This shouldn’t behave differently for JAVA 8 and 11, should it?
The difference might be related to the defaults in the java.exe settings, those changed with Java 9: https://bugs.openjdk.java.net/browse/JDK-8073320. The old Java default was 'dpi aware' the new is 'dpi aware per monitor'. However, the Eclipse executable has 'dpi aware' set as default, see https://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/features/org.eclipse.equinox.executable.feature/library/win32/eclipse.exe.manifest. How do you launch the different copies of Eclipse, i.e., which executable do you use? For myself, I only observed behavior 3 when launching a runtime instance with javaw.exe directly. Resent Windows 10 supports DPI awareness settings on a top-level window basis as opposed to a per-process basis, see https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-improvements-for-desktop-applications Maybe this awareness should be used to fix this issue, though I don't have knowledge about the windows APIs, so I cannot help in that direction.
(In reply to Rolf Theunissen from comment #36) > How do you launch the different copies of Eclipse, i.e., which executable do > you use? I'm using windows shortcuts. Each one calls one of the following command lines: 1. "C:\Program Files\Eclipse\Eclipse-2020-06\eclipse.exe" -vm "%JAVA_8_HOME%\bin\javaw.exe" 2. "C:\Program Files\Eclipse\Eclipse-2020-06\eclipse.exe" -vm "%JAVA_11_HOME%\bin\javaw.exe" The eclipse folder itself (especially the eclipse.ini file) remains unchanged. The same is true for build I20210310-2050, which I downloaded in the course of this issue. (But there of course Java 8 is not possible anymore.)
(In reply to Detlef Keil from comment #37) > (In reply to Rolf Theunissen from comment #36) > > How do you launch the different copies of Eclipse, i.e., which executable do > > you use? > I'm using windows shortcuts. Each one calls one of the following command > lines: > 1. "C:\Program Files\Eclipse\Eclipse-2020-06\eclipse.exe" -vm > "%JAVA_8_HOME%\bin\javaw.exe" > 2. "C:\Program Files\Eclipse\Eclipse-2020-06\eclipse.exe" -vm > "%JAVA_11_HOME%\bin\javaw.exe" > > The eclipse folder itself (especially the eclipse.ini file) remains > unchanged. > > The same is true for build I20210310-2050, which I downloaded in the course > of this issue. (But there of course Java 8 is not possible anymore.) The windows Task Manager shows wonderful results :-S - When launching with -vm "%JAVA_11_HOME%\bin\javaw.exe", I see a javaw.exe (OpenJDK Platform binary) process with a Eclipse child, this configuration locks up. - When launching with -vm "%JAVA_11_HOME%\bin", I see a eclipse.exe process with a Eclipse child, the window is scaled up on the other screen. The non scaling behavior is enabled when: right click on eclipse.exe > Properties > Compatibility > Change high DPI settings > Override ... > Application With this change, scaling is disabled for both ways to start the process, and the lockup does not occur.
(In reply to Rolf Theunissen from comment #38) > The non scaling behavior is enabled when: right click on eclipse.exe > > Properties > Compatibility > Change high DPI settings > Override ... > > Application > With this change, scaling is disabled for both ways to start the process, > and the lockup does not occur. For me as well the other two options under "Override high DPI..." prevent the hang: - As you said, option "Application" seems to scale the Eclipse window always like on the mains screen (100% for me). - Option "System" even scales the whole Eclipse window as configured in the Windows 10 settings. (for me 100% on the left screen and 125% on the right screen.) - Option "System (enhanced)" is like Option "System" only that it seems to need more time to recalculate when moving the Eclipse window from one screen to another. So this is a very good workaround in addition to those meantioned in comment #29 and comment #30.
Moving out of 4.21
Moving out of 4.23
Is it possible to at least display a warning that Eclipse will hang when you have two monitors with different DPI settings? That way, people at least know what's going on when Eclipse suddenly stops working. I would iterate all screens during startup and display a warning with this text: --- Detected dual-screen with different DPI settings Due to a bug in SWT, Eclipse has a high chance to hang when it tries to display a tooltip which extends over both screens. To prevent this, please change the zoom factor on Windows to 100% for all displays. --- If possible include a step-by-step guide a link to a wiki page with the steps for Windows.
(In reply to Aaron Digulla from comment #42) > Detected dual-screen with different DPI settings > > Due to a bug in SWT, Eclipse has a high chance to hang when it tries to > display a tooltip which extends over both screens. > > To prevent this, please change the zoom factor on Windows to 100% for all > displays. Please keep in mind, that people who changed their DPI settings sometimes have some sort of sight disorder or at least wear glasses. Therefore I suggest rather to give them advice how to change the compatibility settings of the "eclipse.exe" as mentioned in comment #38 and comment #39.
(In reply to Detlef Keil from comment #43) > (In reply to Aaron Digulla from comment #42) > > Detected dual-screen with different DPI settings > > > > Due to a bug in SWT, Eclipse has a high chance to hang when it tries to > > display a tooltip which extends over both screens. > > > > To prevent this, please change the zoom factor on Windows to 100% for all > > displays. > > Please keep in mind, that people who changed their DPI settings sometimes > have some sort of sight disorder or at least wear glasses. Therefore I > suggest rather to give them advice how to change the compatibility settings > of the "eclipse.exe" as mentioned in comment #38 and comment #39. The behavior depends on how eclipse gets launched. In the default configuration this issue is not triggered, only when Eclipse is launched with the javaw.exe executable this issue is triggered, this behavior difference is the scope of Bug 572262. Detecting this situation and detecting the monitor resolutions seems not a trivial change. Someone with the appropriate knowledge should look into this. If you happened to find that person, you could better ask him to really fix this issue. The simplest workaround is to not include "javaw.exe" in the -vm option. At least in my configuration launching with eclipse.exe and only the path to the jvm the problem is not triggered. so change: -vm "%JAVA_11_HOME%\bin\javaw.exe" to: -vm "%JAVA_11_HOME%\bin" This is something that could be added to the release notes of Eclipse.
