Community
Participate
Working Groups
Testing Eclipse 4.6.1 with Wayland on Fedora 25 on a Macbook with retina display. When I start up eclipse on the retina display the icons in menues, and the header of the editor, header of the navigation sidebar and the icons in the navigation sidebar are scaled to about double the expected size. However, the icons in the toolbar is scaled correctly. Then when I attach a secondary screen with a regular resolution and move eclipse to that screen. It seems that ALL the icons, including the toolbar, gets scaled to double the expected size. Under X everything seems to be scaled as I expect.
I haven't experimented much with this. Last time I experimented with HiDpi, I had hi-res on my main screen and regular DPI on other screens. With HiDpi turned on, eclipse looked ok on main screen, but oversized on other screens. (This was X11). I haven't tested on Wayland yet. Does HiDpi work better on wayland in general? I.e, does it auto-scale on a per-monitor basis as oppose to globally?
Under X11 your the "eclipse looked ok on main screen, but oversized on other screens" is the expected behaviour due to X11 only supporting one global DPI. However, under wayland you can have separate DPI for each monitor, so applications will be auto-scaled on a per-monitor basis. However, I assume you must listen to some wayland dpi-change event, and re-scale the icons that are getting the wrong size.... or possibly use some GTK3 widget that handles that automatically.
(In reply to Mattias Eriksson from comment #2) > Under X11 your the "eclipse looked ok on main screen, but oversized on other > screens" is the expected behaviour due to X11 only supporting one global > DPI. However, under wayland you can have separate DPI for each monitor, Interesting. At the moment we're working on getting Eclipse to function on Wayland, (there are some glitches). Once that's done, we hope to investigate HiDpi on wayland also.
Please see my screenshot attachments in https://bugs.eclipse.org/bugs/show_bug.cgi?id=496923 I believe that eclipse scales most things better under Wayland than X11 (there are screenshots of running under both there, see for yourself), with the exception that some icons are "oversize" on Wayland but not X11 (for example, the trash can on the heap status indicator, the icons to the left of the tab titles, and _everything_ in the Project Explorer. X11 sometimes gets things too small. I agree just getting eclipse to stay up and running long enough to do meaningful work is probably a first priority, but it almost works so nice under Wayland, it's tough to switch back to X11 (especially because of some of the "smallness"). I'm not sure If I can just leave this original bug report, or if I have to open up multiple new bug reports for each issue I mentioned above, and if the latter, _where_ I should be opening these bugs... Any help would be appreciated!
Note this may be a GTK3 problem instead of a Wayland problem, running eclipse by exporting the environment variable SWT_GTK=0 (which I believe forces a fallback to GTK2) results in Attachment #268538 [details] of https://bugs.eclipse.org/bugs/show_bug.cgi?id=496923...compare to the other attachments in this bug report. GTK2 has other rendering problems, but at least it scales the icons correctly!
Created attachment 269828 [details] Screenshot of toolbar icon sizes
Using Eclipse Oxygen Release (4.7.0) on Ubuntu 17.04 I experience a similar issue. Toolbar icons are really small. My display resolution is 1920 x 1080. Attached screenshot shows gedit and file browser on the left, for comparison sake.
There was an overhaul of HiDPI support in 4.8/4.9, can you please check using an up-to-date I-build and see if the issue is reproducible?
Created attachment 277151 [details] Problem persists with 4.10 Problem still exists in Eclipse 4.10 on Arch Linux. Check the attachment, the toolbar icons are correct size however the Project Explorer icon, menu bar icons and other are double the size. The DE is Gnome and issue only appears when display scale > 100%
Sravan could you take a look?
@eric, I did look into this issue. I can reproduce this issue on fedora 29. The problem is in hidpi feature we use cairo drawing to scale up the images. The backend X11 doesn't scale the images again. But that is not the case with Wayland. By just changing the backend to wayland I can see double scaling. We need to figure out a way to disable hidpi scaling in wayland backend. I tried to find a way through documentation but I am not able to get this information. Can you help me in this regard? -Sravan
(In reply to Sravan Kumar Lakkimsetti from comment #11) > @eric, > > I did look into this issue. I can reproduce this issue on fedora 29. The > problem is in hidpi feature we use cairo drawing to scale up the images. The > backend X11 doesn't scale the images again. But that is not the case with > Wayland. By just changing the backend to wayland I can see double scaling. > > We need to figure out a way to disable hidpi scaling in wayland backend. I > tried to find a way through documentation but I am not able to get this > information. Can you help me in this regard? > > -Sravan Would it be easier if we just didn't scale images on Wayland at all? If Wayland is scaling these on its own, do we need to be doing it in SWT?
(In reply to Eric Williams from comment #12) > (In reply to Sravan Kumar Lakkimsetti from comment #11) > > @eric, > > > > I did look into this issue. I can reproduce this issue on fedora 29. The > > problem is in hidpi feature we use cairo drawing to scale up the images. The > > backend X11 doesn't scale the images again. But that is not the case with > > Wayland. By just changing the backend to wayland I can see double scaling. > > > > We need to figure out a way to disable hidpi scaling in wayland backend. I > > tried to find a way through documentation but I am not able to get this > > information. Can you help me in this regard? > > > > -Sravan > > Would it be easier if we just didn't scale images on Wayland at all? If > Wayland is scaling these on its own, do we need to be doing it in SWT? I did try to stop scaling from SWT side. We use device_scale parameter in cairo surface to define the scale_factor in gtk widgets. This affects at both cairo and wayland. So stopping at cairo results in stopping at wayland also. I could not figure how to stop only at Wayland.
(In reply to Sravan Kumar Lakkimsetti from comment #13) > (In reply to Eric Williams from comment #12) > > (In reply to Sravan Kumar Lakkimsetti from comment #11) > > > @eric, > > > > > > I did look into this issue. I can reproduce this issue on fedora 29. The > > > problem is in hidpi feature we use cairo drawing to scale up the images. The > > > backend X11 doesn't scale the images again. But that is not the case with > > > Wayland. By just changing the backend to wayland I can see double scaling. > > > > > > We need to figure out a way to disable hidpi scaling in wayland backend. I > > > tried to find a way through documentation but I am not able to get this > > > information. Can you help me in this regard? > > > > > > -Sravan > > > > Would it be easier if we just didn't scale images on Wayland at all? If > > Wayland is scaling these on its own, do we need to be doing it in SWT? > > I did try to stop scaling from SWT side. We use device_scale parameter in > cairo surface to define the scale_factor in gtk widgets. This affects at > both cairo and wayland. So stopping at cairo results in stopping at wayland > also. I could not figure how to stop only at Wayland. Can you point me to where this is happening? It might be possible to de-couple GDK and Cairo so that we only draw on surfaces created via Cairo, and not GTK/GDK.
The way we scale on GTK is by drawing on surfaces. Cairo surface has an attribute device_scale. This holds the scale factor information at surface creation time. Surface holds the image which needs to be drawn. Now the way this works is, if the source surface's device_scale and target surface's device scale are same no scaling is applied while transferring image from source to destination. if the source's device scale is higher than the target's then a scale factor of target's device scale/ source's device scale (if source is at 2 and target is at 1 then a scale factor of 1/2 i.e 0.5 is applied while transferring image from source to target) Similarly if source is at 1 and target is at 2 a scale factor of 2 is applied during the image transfer. In the code I am manipulating this device scale using the following api void cairo_surface_get_device_scale () void cairo_surface_set_device_scale () I set the device scale appropriately in the code. This what gives us the auto scale of images. The issue with Wayland is some how wayland is redrawing these images. and resulting in one more scale up. In the code please look at the cairo_surface_set_device_scale call. this is the call that sets appropriate scale for the images. Please note. In the hidpi implementation I tried to completely eliminate GDK. Please take a look and see if you can find some thing here.
(In reply to Sravan Kumar Lakkimsetti from comment #15) > Please note. In the hidpi implementation I tried to completely eliminate > GDK. Please take a look and see if you can find some thing here. In Image.java we were using gdk_window_begin_draw_frame() to eventually create the surface. For the GTK4 port I removed this and just use cairo_image_surface_create(). I think we can probably use this for GTK3 as well -- it might be causing the bug here.
Does GDK_SCALE=2 no longer work?
(In reply to Eric Williams from comment #17) > Does GDK_SCALE=2 no longer work? for me GDK_SCALE=2 is inconsistent. I set scalefactor to 200% in the display settings
(In reply to Sravan Kumar Lakkimsetti from comment #18) > (In reply to Eric Williams from comment #17) > > Does GDK_SCALE=2 no longer work? > > for me GDK_SCALE=2 is inconsistent. I set scalefactor to 200% in the display > settings Okay. Can you please post a screenshot of Snippet367 running that shows the double scaling? I just want to confirm that I can accurately reproduce the issue.
Sorry I was on leave yesterday. I will attach current and expected(this will be taken on x11) screenshots.
Created attachment 279235 [details] snippet367 at 100%
Created attachment 279236 [details] snippet367 at 200% on x11 (expected behavior)
Created attachment 279237 [details] snippet367 at 200% on Wayland (current behavior)
Thanks Sravan, this is helpful.
So in Snippet367 it looks like "cases" 1, 2, and 5 are broken (double scaled).
(In reply to Eric Williams from comment #25) > So in Snippet367 it looks like "cases" 1, 2, and 5 are broken (double > scaled). Yes. Also check eclipse workbench there might be some more cases that are not covered by this. Fixing Case 1 would mostly fix other cases. Please focus on case 1 first.
(In reply to Sravan Kumar Lakkimsetti from comment #26) > (In reply to Eric Williams from comment #25) > > So in Snippet367 it looks like "cases" 1, 2, and 5 are broken (double > > scaled). > > Yes. Also check eclipse workbench there might be some more cases that are > not covered by this. > > Fixing Case 1 would mostly fix other cases. Please focus on case 1 first. Sounds good, thanks for confirming. I'll be looking at this with priority.
Alright I think I've found the cause of this. In Device.init() we set the Cairo device scale via cairo_surface_get_device_scale(). The only problem is that the surface created using the root window seems to have the wrong scale factor. I haven't checked if this is the case with X11, but it certainly is on Wayland. The consequence is that we are scaling up on pretty much most drawing operations, despite not needing to, which leads to the double scaling. So far I've played around with a fix by overriding Drawable.isAutoScalable() in Control and other palces, which seems to work. I'll provide a Gerrit later this week.
Created attachment 279282 [details] Gnome x11 100% with patch
Created attachment 279283 [details] Gnome x11 200% with patch
(In reply to Eric Williams from comment #28) > Alright I think I've found the cause of this. > > In Device.init() we set the Cairo device scale via > cairo_surface_get_device_scale(). The only problem is that the surface > created using the root window seems to have the wrong scale factor. I > haven't checked if this is the case with X11, but it certainly is on Wayland. > > The consequence is that we are scaling up on pretty much most drawing > operations, despite not needing to, which leads to the double scaling. So > far I've played around with a fix by overriding Drawable.isAutoScalable() in > Control and other palces, which seems to work. I'll provide a Gerrit later > this week. There are different implementations for gnome and kde. in gnome we use cairo scaling. In kde we don't. This is determined by api DPIUtil.setUseCairoAutoScale(); The way we determine whether we can use cairo scaling is available to us is by comparing cairo scale applied on an example surface and the monitor scale factor. In case of kde monitor scale factor can be more(you can get fractional scale as well) but cairo scale will remain at 1. In case of gnome both will be equal. this is the feature I am using to determine whether we need to use cairo scale or our own scaling algorithm(using autoScaleUp/autoScaleDown methods)
(In reply to Sravan Kumar Lakkimsetti from comment #31) > (In reply to Eric Williams from comment #28) > > Alright I think I've found the cause of this. > > > > In Device.init() we set the Cairo device scale via > > cairo_surface_get_device_scale(). The only problem is that the surface > > created using the root window seems to have the wrong scale factor. I > > haven't checked if this is the case with X11, but it certainly is on Wayland. > > > > The consequence is that we are scaling up on pretty much most drawing > > operations, despite not needing to, which leads to the double scaling. So > > far I've played around with a fix by overriding Drawable.isAutoScalable() in > > Control and other palces, which seems to work. I'll provide a Gerrit later > > this week. > > There are different implementations for gnome and kde. in gnome we use cairo > scaling. In kde we don't. This is determined by api > DPIUtil.setUseCairoAutoScale(); > > The way we determine whether we can use cairo scaling is available to us is > by comparing cairo scale applied on an example surface and the monitor scale > factor. In case of kde monitor scale factor can be more(you can get > fractional scale as well) but cairo scale will remain at 1. In case of gnome > both will be equal. this is the feature I am using to determine whether we > need to use cairo scale or our own scaling algorithm(using > autoScaleUp/autoScaleDown methods) I see, okay. I'll upload a more complete patch, it sounds like on GNOME we don't need to be scaling up or down, as GTK3 handles most of this for us. From what I remember, a lot of the HiDPI stuff was written during GTK2 days which aren't a concern anymore.
(In reply to Eric Williams from comment #32) > (In reply to Sravan Kumar Lakkimsetti from comment #31) > > (In reply to Eric Williams from comment #28) > > > Alright I think I've found the cause of this. > > > > > > In Device.init() we set the Cairo device scale via > > > cairo_surface_get_device_scale(). The only problem is that the surface > > > created using the root window seems to have the wrong scale factor. I > > > haven't checked if this is the case with X11, but it certainly is on Wayland. > > > > > > The consequence is that we are scaling up on pretty much most drawing > > > operations, despite not needing to, which leads to the double scaling. So > > > far I've played around with a fix by overriding Drawable.isAutoScalable() in > > > Control and other palces, which seems to work. I'll provide a Gerrit later > > > this week. > > > > There are different implementations for gnome and kde. in gnome we use cairo > > scaling. In kde we don't. This is determined by api > > DPIUtil.setUseCairoAutoScale(); > > > > The way we determine whether we can use cairo scaling is available to us is > > by comparing cairo scale applied on an example surface and the monitor scale > > factor. In case of kde monitor scale factor can be more(you can get > > fractional scale as well) but cairo scale will remain at 1. In case of gnome > > both will be equal. this is the feature I am using to determine whether we > > need to use cairo scale or our own scaling algorithm(using > > autoScaleUp/autoScaleDown methods) > > I see, okay. I'll upload a more complete patch, it sounds like on GNOME we > don't need to be scaling up or down, as GTK3 handles most of this for us. > From what I remember, a lot of the HiDPI stuff was written during GTK2 days > which aren't a concern anymore. Yes thats correct. With cairo scaling we don't need to do scale up and down from eclipse side.
(In reply to Sravan Kumar Lakkimsetti from comment #33) > Yes thats correct. With cairo scaling we don't need to do scale up and down > from eclipse side. Cool, the latest patch addresses this. Can you test the Gerrit? If all is good we can probably merge soon once I clean the patch up a bit.
Copying discussion from https://bugs.eclipse.org/bugs/show_bug.cgi?id=496849#c18: --------------------------------------------------------------------------------- (In reply to Waqas Ilyas from comment #18) > (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.
Created attachment 279342 [details] Screenshots with patchset 3 The problem appears to be solved. please see attached screen shots
(In reply to Niraj Modi from comment #35) > Copying discussion from > https://bugs.eclipse.org/bugs/show_bug.cgi?id=496849#c18: > ----------------------------------------------------------------------------- > ---- > (In reply to Waqas Ilyas from comment #18) > > (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. Yes, I need to tweak the isGNOME check to include things like "ubuntu:GNOME". Will clean this up next week.
Gerrit change https://git.eclipse.org/r/146095 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3f4ba4829811a53d8db59b35fed6a7d8a078aca9
(In reply to Eclipse Genie from comment #38) > Gerrit change https://git.eclipse.org/r/146095 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=3f4ba4829811a53d8db59b35fed6a7d8a078aca9 In master now.
Verified in I20190820-0600.
