Community
Participate
Working Groups
Created attachment 285027 [details] Example plug-in to reproduce the problem with. To reproduce: 1. Import plug-in from attached archive "ExampleViewIcon.zip". 1.1. Alternatively, create a plug-in project with example 3.x view contribution, replace the view icon with an icon that is not 16x16 or 32x32, but instead is e.g. 200x200 px. 2. Debug Eclipse with the example plug-in in the debuggee Eclipse. 3. Open "Sample View". 4. Observe tab folder displaying a huge icon and oversized tabs to accommodate the huge icon.
Created attachment 285028 [details] Screenshot with the attached reproducer.
I think that is by design. Multiple RCP clients depend on the toolbar to size to the used icon size. IIRC I have also seen patches in the past, which made the toolbar adjust dynamically to added icons.
If this is "by design" its a recent addition. We are not seeing this bug with 4.15.
(In reply to Simeon Andreev from comment #3) > If this is "by design" its a recent addition. We are not seeing this bug > with 4.15. From https://bugs.eclipse.org/bugs/show_bug.cgi?id=569691#c2: IIRC I have also seen patches in the past, which made the toolbar adjust dynamically to added icons. IIRC it used to be that the toolbar got the size of the first icon.
OK, I see the view icon is actually taking the original icon size (for whatever reason) also on 4.15. I'll attach a 2nd reproducer once I have it and I'll change the description. The problem in our product is in the view toolbar, not with the view tabs. I assumed the large view icon was the same problem, but apparently its not. Background: We have tests that zoom in/out client area of a view and expect specific results. The client area however (with 4.18+) is now much smaller due to extremely large view toolbar (due to a large icon for an action).
For whatever reason large icons in view toolbars in our product are normal sized, until sometime after 4.15 (we assume 4.18 but we can't be sure, the large icons are a new addition in our product). Maybe some bug fix restored the "expected" behaviour of icons having original size. We'll adjust icons in our product and I'll try to find what changed after 4.15.
(In reply to Simeon Andreev from comment #6) > For whatever reason large icons in view toolbars in our product are normal > sized, until sometime after 4.15 (we assume 4.18 but we can't be sure, the > large icons are a new addition in our product). Maybe some bug fix restored > the "expected" behaviour of icons having original size. > > We'll adjust icons in our product and I'll try to find what changed after > 4.15. FYI, there is difference w.r.t. how to icon sizes is handled on the different platforms. For instance, the native windows APIs assume that all icons in a toolbar have the same size. Therefore, on windows, the first icon in a toolbar determines the size of all icons.
(In reply to Rolf Theunissen from comment #7) > FYI, there is difference w.r.t. how to icon sizes is handled on the > different platforms. For instance, the native windows APIs assume that all > icons in a toolbar have the same size. Therefore, on windows, the first icon > in a toolbar determines the size of all icons. We are on Linux only. Could you point me to the code that has the "final say" on toolbar size? I notice some changes for bug 90757 but reverting those changes in our product has no effect; something else must have changed. Note that we have no intention to revert anything, we just want to know why our platform works with large icons in a view/editor toolbar.
Created attachment 285040 [details] Example plug-in to reproduce the problem with. > (In reply to Rolf Theunissen from comment #7) > > Therefore, on windows, the first icon > > in a toolbar determines the size of all icons. OK this seems to have been the case for Linux too, until some time during 4.17 development cycle. I've been trying to reproduce the problem we see in our product with the first action in the view toolbar. However our problems are with icons that are not the first one. For reproduction, import plug-in from "ExampleViewToolbarIcon.zip", debug and open "Sample View". In the view toolbar, second action icon should be small. The problem (large icon) is not seen with: Eclipse SDK Version: 2020-09 (4.17) Build id: I20200803-1800 The problem is seen with: Eclipse SDK Version: 2020-09 (4.17) Build id: I20200812-0710 (I have no builds in-between, but the interval should make bisection easy)
Created attachment 285041 [details] Screenshots when comparing 4.17 builds I20200803 and I20200812. Largest icon determines toolbar size in the latter build.
First commit I see this is: https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=a05ee0e05540ae5f068f127d687828dc3cdf0341 For bug 564097.
(In reply to Simeon Andreev from comment #11) > First commit I see this is: > https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=a05ee0e05540ae5f068f127d687828dc3cdf0341 > > For bug 564097. Applying the following change on top of that commit restores the old behaviour: diff --git a/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os.c b/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os.c index f3cb10ca5c..3eb8132b26 100644 --- a/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os.c +++ b/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os.c @@ -6828,6 +6828,42 @@ JNIEXPORT jlong JNICALL GTK_NATIVE(gtk_1image_1new_1from_1pixbuf) } #endif +#ifndef NO_gtk_1image_1set_1from_1gicon__JJ +JNIEXPORT void JNICALL GTK_NATIVE(gtk_1image_1set_1from_1gicon__JJ) + (JNIEnv *env, jclass that, jlong arg0, jlong arg1) +{ + GTK_NATIVE_ENTER(env, that, gtk_1image_1set_1from_1gicon__JJ_FUNC); +/* + gtk_image_set_from_gicon((GtkImage *)arg0, (GIcon *)arg1); +*/ + { + GTK_LOAD_FUNCTION(fp, gtk_image_set_from_gicon) + if (fp) { + ((void (CALLING_CONVENTION*)(GtkImage *, GIcon *))fp)((GtkImage *)arg0, (GIcon *)arg1); + } + } + GTK_NATIVE_EXIT(env, that, gtk_1image_1set_1from_1gicon__JJ_FUNC); +} +#endif + +#ifndef NO_gtk_1image_1set_1from_1gicon__JJI +JNIEXPORT void JNICALL GTK_NATIVE(gtk_1image_1set_1from_1gicon__JJI) + (JNIEnv *env, jclass that, jlong arg0, jlong arg1, jint arg2) +{ + GTK_NATIVE_ENTER(env, that, gtk_1image_1set_1from_1gicon__JJI_FUNC); +/* + gtk_image_set_from_gicon((GtkImage *)arg0, (GIcon *)arg1, (GtkIconSize)arg2); +*/ + { + GTK_LOAD_FUNCTION(fp, gtk_image_set_from_gicon) + if (fp) { + ((void (CALLING_CONVENTION*)(GtkImage *, GIcon *, GtkIconSize))fp)((GtkImage *)arg0, (GIcon *)arg1, (GtkIconSize)arg2); + } + } + GTK_NATIVE_EXIT(env, that, gtk_1image_1set_1from_1gicon__JJI_FUNC); +} +#endif + #ifndef NO_gtk_1image_1set_1from_1icon_1name__J_3B JNIEXPORT void JNICALL GTK_NATIVE(gtk_1image_1set_1from_1icon_1name__J_3B) (JNIEnv *env, jclass that, jlong arg0, jbyteArray arg1) diff --git a/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_stats.c b/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_stats.c index 003d5d9360..2ea0084278 100644 --- a/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_stats.c +++ b/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_stats.c @@ -543,6 +543,8 @@ char * GTK_nativeFunctionNames[] = { "gtk_1image_1new_1from_1icon_1name___3B", "gtk_1image_1new_1from_1icon_1name___3BI", "gtk_1image_1new_1from_1pixbuf", + "gtk_1image_1set_1from_1gicon__JJ", + "gtk_1image_1set_1from_1gicon__JJI", "gtk_1image_1set_1from_1icon_1name__J_3B", "gtk_1image_1set_1from_1icon_1name__J_3BI", "gtk_1image_1set_1from_1pixbuf", diff --git a/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_stats.h b/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_stats.h index 3b73e83634..334e7870e0 100644 --- a/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_stats.h +++ b/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os_stats.h @@ -541,6 +541,8 @@ typedef enum { gtk_1image_1new_1from_1icon_1name___3B_FUNC, gtk_1image_1new_1from_1icon_1name___3BI_FUNC, gtk_1image_1new_1from_1pixbuf_FUNC, + gtk_1image_1set_1from_1gicon__JJ_FUNC, + gtk_1image_1set_1from_1gicon__JJI_FUNC, gtk_1image_1set_1from_1icon_1name__J_3B_FUNC, gtk_1image_1set_1from_1icon_1name__J_3BI_FUNC, gtk_1image_1set_1from_1pixbuf_FUNC, diff --git a/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/org/eclipse/swt/internal/gtk/GTK.java b/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/org/eclipse/swt/internal/gtk/GTK.java index cd068b8c6d..209a4ea411 100644 --- a/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/org/eclipse/swt/internal/gtk/GTK.java +++ b/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/org/eclipse/swt/internal/gtk/GTK.java @@ -1466,6 +1466,21 @@ public class GTK extends OS { * @param surface cast=(cairo_surface_t *) */ public static final native void gtk_image_set_from_surface(long image, long surface); + /** + * @method flags=dynamic + * @param image cast=(GtkImage *) + * @param gicon cast=(GIcon *) + * @param size cast=(GtkIconSize) + */ + /* [GTK3 only] */ + public static final native void gtk_image_set_from_gicon(long image, long gicon, int size); + /** + * @method flags=dynamic + * @param image cast=(GtkImage *) + * @param gicon cast=(GIcon *) + */ + /* [GTK4 only] */ + public static final native void gtk_image_set_from_gicon(long image, long gicon); /** * @method flags=dynamic * @param icon_name cast=(const gchar *) diff --git a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/ToolItem.java b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/ToolItem.java index 643556383d..a0590d1ad9 100644 --- a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/ToolItem.java +++ b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/ToolItem.java @@ -717,7 +717,8 @@ long gtk_enter_notify_event (long widget, long event) { if (imageList != null) { int index = imageList.indexOf (hotImage); if (index != -1 && imageHandle != 0) { - GTK.gtk_image_set_from_surface(imageHandle, hotImage.surface); + long pixbuf = imageList.getPixbuf (index); + GTK.gtk_image_set_from_gicon(imageHandle, pixbuf); } } } @@ -774,7 +775,8 @@ long gtk_leave_notify_event (long widget, long event) { if (imageList != null) { int index = imageList.indexOf (image); if (index != -1 && imageHandle != 0) { - GTK.gtk_image_set_from_surface(imageHandle, image.surface); + long pixbuf = imageList.getPixbuf (index); + GTK.gtk_image_set_from_gicon(imageHandle, pixbuf); } } } @@ -798,7 +800,6 @@ void hookEvents () { super.hookEvents (); if ((style & SWT.SEPARATOR) != 0) return; OS.g_signal_connect_closure (handle, OS.clicked, display.getClosure (CLICKED), false); - /* * Feature in GTK. GtkToolItem does not respond to basic listeners * such as button-press, enter-notify to it. The fix is to assign @@ -1188,10 +1189,10 @@ void _setImage (Image image) { } else { imageList.put (imageIndex, image); } - - GTK.gtk_image_set_from_surface(imageHandle, image.surface); + long pixbuf = imageList.getPixbuf (imageIndex); + GTK.gtk_image_set_from_gicon(imageHandle, pixbuf); } else { - GTK.gtk_image_set_from_surface(imageHandle, 0); + GTK.gtk_image_set_from_gicon(imageHandle, 0); } /* * If Text/Image of a tool-item changes, then it is @@ -1449,26 +1450,4 @@ String getNameText() { } return nameText; } - -@Override -long dpiChanged(long object, long arg0) { - super.dpiChanged(object, arg0); - - if (image != null) { - image.internal_gtk_refreshImageForZoom(); - setImage(image); - } - - if (hotImage != null) { - hotImage.internal_gtk_refreshImageForZoom(); - setHotImage(hotImage); - } - - if (disabledImage != null) { - disabledImage.internal_gtk_refreshImageForZoom(); - setDisabledImage(disabledImage); - } - - return 0; -} }
Behaviour on Windows 10 with 4.18 M1 (I have nothing newer on Windows 10) is consistent with "old" Linux (GTK) behaviour. If the large icon is the first in the view toolbar, the toolbar is large also. If the large icon is not first, the toolbar is not large.
Hi Paul, could you take a look here? Best regards and thanks, Simeon
I find it always confusing that changing of toolbar icons "does not work" because the toolbar use the first icon/control/whatever wtf to determine its height instead of the height of the largest item. This can lead to really poor UIs as one is forced to place some kind of useless buttons/icons in front to make sure controls are not cut off or icons are shrinked to unrecognizable pixel-garbage. Honestly, why someone places a 200x200px icon in a toolbar if its supposed to be 16x16 pixel? That doesn't make sense and I would assume this is a bug of the plugin and not of the toolbar. See Bug 568148 where it is also stated that toolbar is supposed to adjusting to icon size in GTK (and support is missing on Windows).
(In reply to Christoph Laeubrich from comment #15) > Honestly, why someone places a 200x200px icon in a toolbar if its supposed > to be 16x16 pixel? Because it worked so far. I doubt the developers that added the icons cared how large the icons are, as long as their view looked fine when used. > That doesn't make sense and I would assume this is a bug > of the plugin and not of the toolbar. Unfortunately this is not about a single plug-in. The product in question has about 80 "oversized" icons (that have gathered with years of development); going over them, finding out how they are used and fixing them will take a long while. Rather than debate what is meaningful behaviour (you can open a bug for that), I would like a return to the previous behaviour. I highly doubt the fix for bug 564097 was intended to have "side effects" like this.
As mentioned before, Gtk-Toolbars have always (or at least for a long time) had support for differently sized icons. Can you try your example without the (i) icon and just the large icon? So that it "worked before" was just a side-effect because it happens to have the size fixed by some other (correctly) sized icon before the incorrectly ones was added Basically the application relied on undefined behavior and this might change some time as it never was API (afaik).
(In reply to Christoph Laeubrich from comment #17) > As mentioned before, Gtk-Toolbars have always (or at least for a long time) > had support for differently sized icons. Can you try your example without > the (i) icon and just the large icon? > > So that it "worked before" was just a side-effect because it happens to have > the size fixed by some other (correctly) sized icon before the incorrectly > ones was added > Basically the application relied on undefined behavior and this might change > some time as it never was API (afaik). Please open a new bug if you want to discuss this, as commented before. Yes, the behaviour changed, and yes, we want the old behaviour back. Rather than make every Eclipse application maintainer have to fix this in their product, official API or not. I'm sure this is not the only "undefined behaviour" (or even "unofficial behaviour") many Eclipse-based applications depend on.
(In reply to Rolf Theunissen from comment #7) > FYI, there is difference w.r.t. how to icon sizes is handled on the > different platforms. For instance, the native windows APIs assume that all > icons in a toolbar have the same size. Therefore, on windows, the first icon > in a toolbar determines the size of all icons. btw this is not completely true. In fact the first *added* icon to the toolbar determine its size, even if one changes all icons in the toolbar afterwards the size does not change and all icons are rescaled (either up or down). On the other hand, under linux the first icon determines how large the maximum icon size is, smaller icons remain their size, larger icon are scaled down, but if one changes all icons this is larger if needed. That's why if one want consistent icons size across platforms/applications/views it is required to provide them at the desired size and that's what at least most eclipse plugins I have seen around already do.
To sum the discussion up: 1) We have a regression on GTK due bug 564097 commit https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=a05ee0e05540ae5f068f127d687828dc3cdf0341 2) Whether or not the original behavior was good or bad is not part of this bug discussion (because it was good for all known releases so far, and because we now see different behavior on different platforms due the change above). 3) If we see a need in improvement for this particular behavior, we should open a dedicated bug and discuss there desired behavior / work on consistent implementation that works for all platforms. As of today the original consistent behavior was changed on GTK only and this is not OK, so I hope Paul could spend some time to restore original behavior for GTK for 4.19, may be together with bug 569233 changes, which seem to be related.
Hello, I was off on holiday so I didn't see this discussion earlier. I have looked into this and the reason behind this revolves around gtk_image_set_from_gicon & the parameter GTK_ICON_SIZE_SMALL_TOOLBAR passed as the GtkIconSize. To fix this bug, we would have to revert back to using gtk_image_set_from_gicon to ensure that icons that are 200x200px (for example) are the correct size. One problem though, if we revert back, the hidpi icons will no longer scale properly. This is because we enforce the GTK_ICON_SIZE_SMALL_TOOLBAR in gtk_image_set_from_gicon. A solution I can think of is to revert back and then use some of the other GtkIconSizes such as GTK_ICON_SIZE_LARGE_TOOLBAR which is 24px for when hidpi is required. Not sure how that will work yet, will look into it. I will also tag Sravan to see what his opinion is on this.
Hi Paul, any news here? Best regards and thanks, Simeon
I was actually waiting for Sravan's opinion on this. But I'll be honest and say from the discussion before, that I agree that icons that are 200x200 should not be used and expected to be scaled down. There should be specific sizes for the base icons, and if you want hidpi support you have to provide larger resolutions.
(In reply to Soraphol (Paul) Damrongpiriyapong from comment #23) > I was actually waiting for Sravan's opinion on this. But I'll be honest and > say from the discussion before, that I agree that icons that are 200x200 > should not be used and expected to be scaled down. There should be specific > sizes for the base icons, and if you want hidpi support you have to provide > larger resolutions. Sorry I was on leave after Jan 4. I will take a look today.
Here is my analysis I believe this regression got introduced with Bug 564097 - [GTK][HiDPI] Cairo auto scaling causing scaling problems When we handle tool bar icons we maintain image cache in the form of ImageList. When ever an image is added to ImageList, its pixbuf is resized to the size of ImageList(size of first of image in the list) see ImageList.set() method. We use pixbuf to set the image to toolbar With bug 564097, code has been changed to use cairo surface to set the toolbar image. During this change we lost resizing of image as done by ImageList.set() method is lost. the best way forward is to resize cairo surface present in the image object in ImageList.set() method at the same location we are doing a resize of pixbuf.
Created attachment 285330 [details] SWT only snippet When you run this snippet you should see a tool bar with 12 red colored buttons with size 16x16. currently this generates a tool bar with odd numbered button as 16x16 and even numbered button with 200x200.
(In reply to Sravan Kumar Lakkimsetti from comment #25) > the best way forward is to resize cairo surface present in the image object > in ImageList.set() method at the same location we are doing a resize of > pixbuf. With the following change, I see normal toolbar sizes in the snippet from comment 26, as well as for the plug-in in the attached archive "ExampleViewToolbarIcon.zip": diff --git a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/internal/ImageList.java b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/internal/ImageList.java index 4f1122b273..1327512c28 100644 --- a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/internal/ImageList.java +++ b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/internal/ImageList.java @@ -220,6 +220,9 @@ void set (int index, Image image) { long scaledPixbuf = GDK.gdk_pixbuf_scale_simple(pixbuf, width, height, GDK.GDK_INTERP_BILINEAR); OS.g_object_unref (pixbuf); pixbuf = scaledPixbuf; + Image scaledImage = Image.gtk_new_from_pixbuf(image.getDevice(), image.type, pixbuf); + image.surface = convertSurface(scaledImage); + scaledImage.dispose(); } long oldPixbuf = pixbufs [index]; if (oldPixbuf != 0) { Unfortunately I don't know which APIs should be used in this case. Setting the surface of the image seems overoptimistic. And I guess there can be side effects to modifying the input image? I tried using another imagine in the ImageList, but that didn't help: diff --git a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/internal/ImageList.java b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/internal/ImageList.java index 4f1122b273..89ad243f88 100644 --- a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/internal/ImageList.java +++ b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/internal/ImageList.java @@ -220,6 +220,8 @@ void set (int index, Image image) { long scaledPixbuf = GDK.gdk_pixbuf_scale_simple(pixbuf, width, height, GDK.GDK_INTERP_BILINEAR); OS.g_object_unref (pixbuf); pixbuf = scaledPixbuf; + image = Image.gtk_new_from_pixbuf(image.getDevice(), image.type, pixbuf); + System.out.println("scaled "+"w="+w+",h="+h+",width="+width+",height="+height+",image.w="+image.getBounds().width+",image.h="+image.getBounds().height); } long oldPixbuf = pixbufs [index]; if (oldPixbuf != 0) {
(In reply to Simeon Andreev from comment #27) > (In reply to Sravan Kumar Lakkimsetti from comment #25) > > the best way forward is to resize cairo surface present in the image object > > in ImageList.set() method at the same location we are doing a resize of > > pixbuf. > > With the following change, I see normal toolbar sizes in the snippet from > comment 26, as well as for the plug-in in the attached archive > "ExampleViewToolbarIcon.zip": > > diff --git a/bundles/org.eclipse.swt/Eclipse > SWT/gtk/org/eclipse/swt/internal/ImageList.java > b/bundles/org.eclipse.swt/Eclipse > SWT/gtk/org/eclipse/swt/internal/ImageList.java > index 4f1122b273..1327512c28 100644 > --- a/bundles/org.eclipse.swt/Eclipse > SWT/gtk/org/eclipse/swt/internal/ImageList.java > +++ b/bundles/org.eclipse.swt/Eclipse > SWT/gtk/org/eclipse/swt/internal/ImageList.java > @@ -220,6 +220,9 @@ void set (int index, Image image) { > long scaledPixbuf = GDK.gdk_pixbuf_scale_simple(pixbuf, > width, height, GDK.GDK_INTERP_BILINEAR); > OS.g_object_unref (pixbuf); > pixbuf = scaledPixbuf; > + Image scaledImage = > Image.gtk_new_from_pixbuf(image.getDevice(), image.type, pixbuf); > + image.surface = convertSurface(scaledImage); > + scaledImage.dispose(); > } > long oldPixbuf = pixbufs [index]; > if (oldPixbuf != 0) { > > Unfortunately I don't know which APIs should be used in this case. Setting > the surface of the image seems overoptimistic. And I guess there can be side > effects to modifying the input image? I tried using another imagine in the > ImageList, but that didn't help: > > diff --git a/bundles/org.eclipse.swt/Eclipse > SWT/gtk/org/eclipse/swt/internal/ImageList.java > b/bundles/org.eclipse.swt/Eclipse > SWT/gtk/org/eclipse/swt/internal/ImageList.java > index 4f1122b273..89ad243f88 100644 > --- a/bundles/org.eclipse.swt/Eclipse > SWT/gtk/org/eclipse/swt/internal/ImageList.java > +++ b/bundles/org.eclipse.swt/Eclipse > SWT/gtk/org/eclipse/swt/internal/ImageList.java > @@ -220,6 +220,8 @@ void set (int index, Image image) { > long scaledPixbuf = GDK.gdk_pixbuf_scale_simple(pixbuf, > width, height, GDK.GDK_INTERP_BILINEAR); > OS.g_object_unref (pixbuf); > pixbuf = scaledPixbuf; > + image = Image.gtk_new_from_pixbuf(image.getDevice(), > image.type, pixbuf); > + System.out.println("scaled > "+"w="+w+",h="+h+",width="+width+",height="+height+",image.w="+image. > getBounds().width+",image.h="+image.getBounds().height); > } > long oldPixbuf = pixbufs [index]; > if (oldPixbuf != 0) { This patch can be a good workaround for the problem. But complete solution will be to modify ImageList class to cache surfaces instead of pixbuf(pixbufs are used in gtk2 and we don't support them anymore). While caching surface we should cache resized surface. This way we will not touch input image. Also since ImageList is an internal class we should be good to add and remove public methods.
(In reply to Sravan Kumar Lakkimsetti from comment #28) > This patch can be a good workaround for the problem. > > But complete solution will be to modify ImageList class to cache surfaces > instead of pixbuf(pixbufs are used in gtk2 and we don't support them > anymore). While caching surface we should cache resized surface. > > This way we will not touch input image. Also since ImageList is an internal > class we should be good to add and remove public methods. I'll try to exchange the pixbuffs with surfaces, though this might take some time; priorities are elsewhere right now.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/175363
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/175409
Created attachment 285417 [details] Snippet 36 with patch
(In reply to Soraphol (Paul) Damrongpiriyapong from comment #32) > Created attachment 285417 [details] > Snippet 36 with patch Looks great!
@paul, Can you please review and test the latest patch? I updated it to support hidpi and fixed problems in ubuntu 20.04. Thanks
Hello, I tested the patch, and the fix for ubuntu seems to not cause any problems on my end (Gnome Wayland). However about the HiDPI fixes, adding the device scaling is the first step. The second problem is that the image list have a cached width and height, therefore when we put the application in hidpi, the icons are small. I have a way to fix this, but it has only worked for the ToolBar/Items and MenuBar/Items. It is to use the dpiChanged callback I created and reset the cached dimensions of the image list.
Created attachment 285433 [details] Hidpi Icons without resetting the imagelist cached dimensions
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/175409 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=b84f0060d2d31f1cd93acbbd184953522870c7d2
Tested in our product, the fix works. Thank you very much!
(In reply to Simeon Andreev from comment #38) > Tested in our product, the fix works. Thank you very much! Yep, many thanks!
Verified. Eclipse SDK Version: 2021-03 (4.19) Build id: I20210216-0600 OS: Linux, v.5.9.15-200.fc33.x86_64, x86_64 / gtk 3.24.24, WebKit 2.30.4 Java version: 11.0.9.1
