Bugzilla – Full Text Bug Listing
| Summary: | [HiDPI] TreeViewer with columns and scaled image draws text over image from first indented item | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Christopher Mindus <christopher> |
| Component: | SWT | Assignee: | Waqas Ilyas <waqas.ilyas> |
| Status: | VERIFIED FIXED | QA Contact: | Niraj Modi <niraj.modi> |
| Severity: | normal | ||
| Priority: | P3 | CC: | Carel.Bast, d.gabriel, ericwill, felix.hirsch, info, loskutov, niraj.modi, orionllmain, serge, shashwat.work, sravankumarl, waqas.ilyas |
| Version: | 4.6 | ||
| Target Milestone: | 4.13 M3 | ||
| Hardware: | PC | ||
| OS: | Windows All | ||
| See Also: |
https://git.eclipse.org/r/146275 https://git.eclipse.org/r/146446 https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=630f371c0cc4e13a2f579468bee859bdd2b0c20f https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=66ca6a1630ac2dff01571775a0c1c985b3debfef |
||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 549422 | ||
| Attachments: | |||
Perhaps some helpful information to fix the problem: 1. DPIUtil.autoScaleUp is not used. 2. org.eclipse.jface.viewers.StyledCellLabelProvider and the paint method that does not use scaling when drawing the cell. 3. Cell information about bounds for image and text. The cell itself delegates this to the row. We have found that we also have this behavior even without additional tree columns, due to the tree using styled cells with it's label provider. Created attachment 271241 [details]
Overlapping Text and Image in PropertiesView
The same problem also occurs in the Properties View if it has icons on the Value column
(In reply to Carel Bast from comment #2) > Created attachment 271241 [details] > Overlapping Text and Image in PropertiesView > > The same problem also occurs in the Properties View if it has icons on the > Value column Tried out the Properties view but could get image and text combination. Can you please share more details on how to reproduce this at our end. For me this happens on HiDPI screens and Dark theme with the most of standard Eclipse views since 4.7 release (and fully reproducible in Eclipse 4.8). Broken tree views include Problem/Error logs, plugins browser, all preferences pages with trees including Appearance->Colors and Fonts and Keys, etc. Project/Package explorers look good, Type hierarchy looks good a few other trees look good too but most of others are not. This makes Dark theme unusable if you use HiDPI monitor and some zoom factor. OS: Windows 10, HiDPI screen with native zoom factor 150% or 175%. Very nice: two years of waiting :-) [for the dark side to take over]. I've been in the Jedi camp with errors since 2016 :-) Thanks guys. I looked through the code, and it doesn't seem to be too hard to fix. The image size is not correctly retrieved or used in the layout of the row. And by the way: this only happens in Tree Views with more than one column (visible or not). (In reply to Niraj Modi from comment #3) > (In reply to Carel Bast from comment #2) > > Created attachment 271241 [details] > > Overlapping Text and Image in PropertiesView > > > > The same problem also occurs in the Properties View if it has icons on the > > Value column > > Tried out the Properties view but could get image and text combination. > Can you please share more details on how to reproduce this at our end. (Sorry Niraj for my very late response.) The PropertiesView with images and text is showing Ecore/EMF properties. You can open any Ecore model and open the properties of one of the items to see the effect as show in the screenshot. Also in Oxygen there is still overlap. It is still reproducible in 4.9 and in 2018-09. I'm a bit frustrated about this bug. Windows + 4k + Dark theme shouldn't be very rare combination. There are a lot of tickets about Dark theme improvements but they doesn't make much sense as Dark theme is unusable in that combination. That's odd. Is there any chance this will be fixed in the near future? (In reply to John Kozlov from comment #8) > Is there any chance this will be fixed in the near future? Sure. Check this: https://wiki.eclipse.org/Platform_UI/How_to_Contribute Below is a snippet that can reproduce the problem on Windows:
public class Snippet170_111 {
public static void main(String[] args) {
Display display = new Display();
final Shell shell = new Shell(display);
shell.setText("Snippet 170");
shell.setLayout(new FillLayout());
// Image icon = new Image(display,
// Snippet170_1.class.getResourceAsStream("eclipse16.png"));
Image icon = new Image(display, new ImageDataProvider() {
@Override
public ImageData getImageData(int zoom) {
if (zoom > 150)
return new ImageData(
Snippet170_1.class.getResourceAsStream("eclipse32.png"));
return new ImageData(
Snippet170_1.class.getResourceAsStream("eclipse16.png"));
}
});
Tree tree = new Tree(shell,
SWT.BORDER | SWT.H_SCROLL | SWT.V_SCROLL | SWT.FULL_SELECTION);
tree.setLinesVisible(true);
new TreeColumn(tree, SWT.LEFT).setWidth(200);
new TreeColumn(tree, SWT.LEFT).setWidth(200);
new TreeColumn(tree, SWT.LEFT).setWidth(200);
TreeItem item = new TreeItem(tree, SWT.NONE);
item.setText(new String[] { "item 00", "item 01", "item 02" });
item.setImage(new Image[] { icon, icon, icon });
shell.pack();
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) {
display.sleep();
}
}
display.dispose();
}
}
Created attachment 279296 [details]
Icons not vertically centered in a TreeItem with scale set to 150
Moreover, on a UHD resolution with scale set to 125% or 150%, the icons on columns other than the first one are also not vertically centered.
New Gerrit change created: https://git.eclipse.org/r/146275 Created attachment 279326 [details] Icons are not correctly sized on Linux with owner draw On linux, the problem can be reproduced by adding the following statement right after creating the Tree (in the snippet under comment #10): tree.addListener(SWT.PaintItem, e -> {}); If a paint listener is added to the Tree (for owner draw), _before_ setting any images on the TreeItem, then images are not properly sized. Just trying to look at the code for GTK which I don't really understand much. Basically in TreeItem.setImage (int index, Image image), following code checks for owner draw on line 1562:
if ((!parent.ownerDraw) && (image != null) && (DPIUtil.getDeviceZoom() != 100)) {
Rectangle imgSize = image.getBounds();
long scaledPixbuf = GDK.gdk_pixbuf_scale_simple(pixbuf, imgSize.width, imgSize.height, GDK.GDK_INTERP_BILINEAR);
if (scaledPixbuf !=0) {
pixbuf = scaledPixbuf;
}
imageList.replacePixbuf(imageIndex, pixbuf);
}
This block was added for the fix of bug #530932, to enable native scaling on GTK. Does anyone know why do we have this check for owner draw?
(In reply to Waqas Ilyas from comment #13) > Created attachment 279326 [details] > Icons are not correctly sized on Linux with owner draw > > On linux, the problem can be reproduced by adding the following statement > right after creating the Tree (in the snippet under comment #10): > tree.addListener(SWT.PaintItem, e -> {}); > > If a paint listener is added to the Tree (for owner draw), _before_ setting > any images on the TreeItem, then images are not properly sized. Wayland or X11? There is bug 507020, which tracks double scaled images in Wayland with HiDPI -- you might be experiencing that. There is also a patch pending for that bug. I was able to reproduce this bug on a fresh install of ubuntu 18.04 (x11), and had a colleague reproduce it on Fedora 30, which I guess is... Wayland? Will try to find out. (In reply to Waqas Ilyas from comment #16) > I was able to reproduce this bug on a fresh install of ubuntu 18.04 (x11), > and had a colleague reproduce it on Fedora 30, which I guess is... Wayland? > Will try to find out. Are you able to test SWT patches? The potential patch is attached to bug 507020. (In reply to Eric Williams from comment #17) > Are you able to test SWT patches? The potential patch is attached to bug > 507020. I downloaded the patch from here: https://git.eclipse.org/r/#/c/146095/ Tried running the snipped in comment #10 (with PaintItem listener added to tree) but I did not see any difference in behavior. I see the following output on console: Running on GNOME? false Surface scale in Device.init() 2.0 cairo scale is 2.0 autoscale? Shell {Snippet 170} false cairo scale is 2.0 autoscale? Tree {} false The "running on GNOME" surprised me a little, so I checked and on my machine XDG_CURRENT_DESKTOP=ubuntu:GNOME. Doesn't seem like it matters though, because I tried forcing it to be true without any change in results. (In reply to Waqas Ilyas from comment #10) > Below is a snippet that can reproduce the problem on Windows: Thanks for the test snippet, can reproduce the problem on Win7 as well. (In reply to Eclipse Genie from comment #12) > New Gerrit change created: https://git.eclipse.org/r/146275 Am verifying it currently. New Gerrit change created: https://git.eclipse.org/r/146446 (In reply to Eclipse Genie from comment #20) > New Gerrit change created: https://git.eclipse.org/r/146446 This patch should fix linux owner draw issues (In reply to Sravan Kumar Lakkimsetti from comment #21) > (In reply to Eclipse Genie from comment #20) > > New Gerrit change created: https://git.eclipse.org/r/146446 > > This patch should fix linux owner draw issues The problem was not detected earlier we were testing owner draw with a full drawing method like in snippet 230. In the example the listener is completely blank so the initial size is more. Gerrit change https://git.eclipse.org/r/146446 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=630f371c0cc4e13a2f579468bee859bdd2b0c20f (In reply to Niraj Modi from comment #19) > (In reply to Waqas Ilyas from comment #10) > > Below is a snippet that can reproduce the problem on Windows: > Thanks for the test snippet, can reproduce the problem on Win7 as well. > > (In reply to Eclipse Genie from comment #12) > > New Gerrit change created: https://git.eclipse.org/r/146275 > Am verifying it currently. Any updates? Are there any concerns on this review? (In reply to Waqas Ilyas from comment #24) > (In reply to Niraj Modi from comment #19) > > (In reply to Waqas Ilyas from comment #10) > > > Below is a snippet that can reproduce the problem on Windows: > > Thanks for the test snippet, can reproduce the problem on Win7 as well. > > > > (In reply to Eclipse Genie from comment #12) > > > New Gerrit change created: https://git.eclipse.org/r/146275 > > Am verifying it currently. > > Any updates? Are there any concerns on this review? Sorry for the delay. Last time I tried, I couldn't reproduce the problem mentioned in comment 11. Please confirm if the problem seen in attachment 279296 [details] can be reproducible with snippet in comment 10. If no please provide an updated snippet for this. Will get back to you early next week. Thanks! (In reply to Niraj Modi from comment #25) > Sorry for the delay. > Last time I tried, I couldn't reproduce the problem mentioned in comment 11. > Please confirm if the problem seen in attachment 279296 [details] can be > reproducible with snippet in comment 10. If no please provide an updated > snippet for this. > > Will get back to you early next week. Thanks! I just tried it again and I can reproduce the problem using this snippet. Except I needed to fix an obvious typo in class name. I set scale to 125% on Windows 10 64-bit, with 3840x2160 resolution. And without the fix, I can reproduce the problem with the snippet in comment# 10. On a side note, while you debug such issues do you keep signing out and in after changing resolution/scaling to try out different combinations on windows. Or is there another way with SWT to mimic the behavior? Any updates? Would you be willing to proceed on this if I split the two fixes? One of them is really critical and the other one (the one mentioned in comment# 11) looks bad but does not disrupt anything. So if that fix is a point of contention we separate it out. (In reply to Waqas Ilyas from comment #27) > Any updates? > > Would you be willing to proceed on this if I split the two fixes? One of > them is really critical and the other one (the one mentioned in comment# 11) > looks bad but does not disrupt anything. So if that fix is a point of > contention we separate it out. Not required, am able to verify both the issues with the gerrit patch on Windows10, planning to release that to master shortly today. Thanks! Gerrit change https://git.eclipse.org/r/146275 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=66ca6a1630ac2dff01571775a0c1c985b3debfef (In reply to Eclipse Genie from comment #29) > Gerrit change https://git.eclipse.org/r/146275 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=66ca6a1630ac2dff01571775a0c1c985b3debfef Thanks Waqas for the fix patch, resolving now. Verified in Build id: I20190821-1800, OS: Windows 10 |
Created attachment 262725 [details] Image showing TreeViewer column problem with text overlapping image As soon as TreeViewer has columns on a high resolution screen and image auto-scaling, the label text of nodes overwrites half of the image (that is scaled automatically), see attached image.