Bug 572285 - [GTK] [HiDPI] Images are not scaled properly
Summary: [GTK] [HiDPI] Images are not scaled properly
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.19   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 4.20 M1   Edit
Assignee: Sravan Kumar Lakkimsetti CLA
QA Contact:
URL:
Whiteboard:
Keywords: regression
: 572632 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-03-25 06:23 EDT by Romain Bioteau CLA
Modified: 2021-04-09 05:42 EDT (History)
3 users (show)

See Also:


Attachments
Example of scaling issue (437.75 KB, image/png)
2021-03-25 06:23 EDT, Romain Bioteau CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Romain Bioteau CLA 2021-03-25 06:23:51 EDT
Created attachment 285945 [details]
Example of scaling issue

At various places like in SWT trees, the images are not scaled properly on Ubuntu 20.04 and a 4k display with a 200% scale factor.

This issue is also impacting my RCP. It seems to happens whether or not i'm providing a @2x asset.

It is a regression as there was no issues on 2020-12.
Comment 1 Andrey Loskutov CLA 2021-03-25 06:31:54 EDT
@Romain: please provide info from Help -> About -> Installation Details -> Configuration -> all values starting with "org.eclipse.swt".

If possible, either provide a small standalone SWT snippet showing a problem or check if any of existing SWT snippets can demonstrate the issue.

Could be related to bug 569691 (and related) fixes.
Comment 2 Romain Bioteau CLA 2021-03-25 07:16:10 EDT
*** System properties:
-Dorg.eclipse.swt.graphics.Resource.reportNonDisposed=true
org.eclipse.swt.graphics.Resource.reportNonDisposed=true
org.eclipse.swt.internal.deviceZoom=200
org.eclipse.swt.internal.gdk.backend=x11
org.eclipse.swt.internal.gtk.theme=Yaru
org.eclipse.swt.internal.gtk.version=3.24.20
sun.java.command=/home/romain/eclipse//plugins/org.eclipse.equinox.launcher_1.6.100.v20201223-0822.jar -os linux -ws gtk -arch x86_64 -showsplash /home/romain/eclipse//plugins/org.eclipse.epp.package.common_4.19.0.20210311-1200/splash.bmp -launcher /home/romain/eclipse/eclipse -name Eclipse --launcher.library /home/romain/eclipse//plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.2.100.v20210209-1541/eclipse_11301.so -startup /home/romain/eclipse//plugins/org.eclipse.equinox.launcher_1.6.100.v20201223-0822.jar --launcher.appendVmargs -exitdata 4000c -product org.eclipse.epp.package.java.product -vm /home/romain/eclipse//plugins/org.eclipse.justj.openjdk.hotspot.jre.full.linux.x86_64_15.0.2.v20210201-0955/jre/bin/java -vmargs -Dosgi.requiredJavaVersion=11 -Dosgi.instance.area.default=@user.home/eclipse-workspace -Dsun.java.command=Eclipse -XX:+UseG1GC -XX:+UseStringDeduplication --add-modules=ALL-SYSTEM -Dosgi.requiredJavaVersion=11 -Dosgi.dataAreaRequiresExplicitInit=true -Dorg.eclipse.swt.graphics.Resource.reportNonDisposed=true -Xms256m -Xmx2048m --add-modules=ALL-SYSTEM -jar /home/romain/eclipse//plugins/org.eclipse.equinox.launcher_1.6.100.v20201223-0822.jar

*** System environment variables:

*** Features:

*** Plug-in Registry:
org.eclipse.swt (3.116.0.v20210302-1107) "Standard Widget Toolkit" [Resolved]
org.eclipse.swt.browser.chromium.gtk.linux.x86_64 (3.116.0.v20210302-1107) "Chromium SWT Widget for GTK" [Resolved]
org.eclipse.swt.gtk.linux.x86_64 (3.116.0.v20210302-1107) "Standard Widget Toolkit for GTK" [Resolved]

*** User Preferences:
/bundle_defaults/org.eclipse.jdt.ui/CallHierarchy.defaultExpandWithConstructorsMembers=java.lang.Runnable.run;java.util.concurrent.Callable.call;org.eclipse.swt.widgets.Listener.handleEvent

*** Current Install Configuration:

Id: org.eclipse.swt, Version: 3.116.0.v20210302-1107, Location: reference:file:plugins/org.eclipse.swt_3.116.0.v20210302-1107.jar
Id: org.eclipse.swt.browser.chromium.gtk.linux.x86_64, Version: 3.116.0.v20210302-1107, Location: reference:file:plugins/org.eclipse.swt.browser.chromium.gtk.linux.x86_64_3.116.0.v20210302-1107.jar
Id: org.eclipse.swt.gtk.linux.x86_64, Version: 3.116.0.v20210302-1107, Location: reference:file:plugins/org.eclipse.swt.gtk.linux.x86_64_3.116.0.v20210302-1107.jar
Comment 3 Sravan Kumar Lakkimsetti CLA 2021-03-25 08:20:31 EDT
The images got double scaled. I will investigate.
Comment 4 Sravan Kumar Lakkimsetti CLA 2021-04-06 13:25:45 EDT
*** Bug 572632 has been marked as a duplicate of this bug. ***
Comment 5 Phil Beauvoir CLA 2021-04-06 13:34:20 EDT
(In reply to Andrey Loskutov from comment #1)
> 
> If possible, either provide a small standalone SWT snippet showing a problem
> or check if any of existing SWT snippets can demonstrate the issue.
> 

I've provided steps to reproduce in Bug 572632.
Comment 6 Eclipse Genie CLA 2021-04-07 06:17:24 EDT
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/178958
Comment 8 Eclipse Genie CLA 2021-04-07 06:35:11 EDT
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/178537
Comment 10 Sravan Kumar Lakkimsetti CLA 2021-04-07 06:38:21 EDT
merged to master
Comment 11 Romain Bioteau CLA 2021-04-07 08:07:56 EDT
(In reply to Sravan Kumar Lakkimsetti from comment #10)
> merged to master

Thanks !
Comment 12 Sravan Kumar Lakkimsetti CLA 2021-04-09 00:06:23 EDT
(In reply to Andrey Loskutov from comment #1)
> @Romain: please provide info from Help -> About -> Installation Details ->
> Configuration -> all values starting with "org.eclipse.swt".
> 
> If possible, either provide a small standalone SWT snippet showing a problem
> or check if any of existing SWT snippets can demonstrate the issue.
> 
> Could be related to bug 569691 (and related) fixes.

this problem is indeed caused by bug 569691. The root cause was we were not considering scaling factor when we are converting an image from cairo surface to GDK pixbuf.

Here is some background. Cairo surface has scalefactor built in. This allows cairo to determine whether image needs to be scaled or not at the time of rendering. To take advantage we deal with 200% image with a scalefactor of 2 at 200% scale.

In case of pixbuf we don't have this facility all the images are treated as 100% images even though the display is at 200%. Because of this the pixbuf gets scaled before rendering.

In this particular path we were converting a cairo surface with a scale factor of 2 to pixbuf. Since the scale factor is 2 the dimensions are of double size. the resulting pixbuf gets created with double size. When this pixbuf is used, the renderer treats all puxbufs as 100% images so the pixbuf is scaled up before rendering. 

This results in double scaling.

The solution is to create pixbuf at 100% dimensions.

We should investigate whether we can eliminate pixbuf completely.
Comment 13 Romain Bioteau CLA 2021-04-09 03:00:43 EDT
(In reply to Sravan Kumar Lakkimsetti from comment #12)
> (In reply to Andrey Loskutov from comment #1)
> > @Romain: please provide info from Help -> About -> Installation Details ->
> > Configuration -> all values starting with "org.eclipse.swt".
> > 
> > If possible, either provide a small standalone SWT snippet showing a problem
> > or check if any of existing SWT snippets can demonstrate the issue.
> > 
> > Could be related to bug 569691 (and related) fixes.
> 
> this problem is indeed caused by bug 569691. The root cause was we were not
> considering scaling factor when we are converting an image from cairo
> surface to GDK pixbuf.
> 
> Here is some background. Cairo surface has scalefactor built in. This allows
> cairo to determine whether image needs to be scaled or not at the time of
> rendering. To take advantage we deal with 200% image with a scalefactor of 2
> at 200% scale.
> 
> In case of pixbuf we don't have this facility all the images are treated as
> 100% images even though the display is at 200%. Because of this the pixbuf
> gets scaled before rendering.
> 
> In this particular path we were converting a cairo surface with a scale
> factor of 2 to pixbuf. Since the scale factor is 2 the dimensions are of
> double size. the resulting pixbuf gets created with double size. When this
> pixbuf is used, the renderer treats all puxbufs as 100% images so the pixbuf
> is scaled up before rendering. 
> 
> This results in double scaling.
> 
> The solution is to create pixbuf at 100% dimensions.
> 
> We should investigate whether we can eliminate pixbuf completely.

Thanks for the explanation. Do you know if there will be a maintenance release for 4.19 ? I don't know if those still exist since the shorter release cycle.
Comment 14 Sravan Kumar Lakkimsetti CLA 2021-04-09 04:34:01 EDT
(In reply to Romain Bioteau from comment #13)
> (In reply to Sravan Kumar Lakkimsetti from comment #12)
> > (In reply to Andrey Loskutov from comment #1)
> > > @Romain: please provide info from Help -> About -> Installation Details ->
> > > Configuration -> all values starting with "org.eclipse.swt".
> > > 
> > > If possible, either provide a small standalone SWT snippet showing a problem
> > > or check if any of existing SWT snippets can demonstrate the issue.
> > > 
> > > Could be related to bug 569691 (and related) fixes.
> > 
> > this problem is indeed caused by bug 569691. The root cause was we were not
> > considering scaling factor when we are converting an image from cairo
> > surface to GDK pixbuf.
> > 
> > Here is some background. Cairo surface has scalefactor built in. This allows
> > cairo to determine whether image needs to be scaled or not at the time of
> > rendering. To take advantage we deal with 200% image with a scalefactor of 2
> > at 200% scale.
> > 
> > In case of pixbuf we don't have this facility all the images are treated as
> > 100% images even though the display is at 200%. Because of this the pixbuf
> > gets scaled before rendering.
> > 
> > In this particular path we were converting a cairo surface with a scale
> > factor of 2 to pixbuf. Since the scale factor is 2 the dimensions are of
> > double size. the resulting pixbuf gets created with double size. When this
> > pixbuf is used, the renderer treats all puxbufs as 100% images so the pixbuf
> > is scaled up before rendering. 
> > 
> > This results in double scaling.
> > 
> > The solution is to create pixbuf at 100% dimensions.
> > 
> > We should investigate whether we can eliminate pixbuf completely.
> 
> Thanks for the explanation. Do you know if there will be a maintenance
> release for 4.19 ? I don't know if those still exist since the shorter
> release cycle.

Sorry there are no maintenance releases planned. But you can build 4.19 using the following commands (you'll need maven)

step 1: get the code and setup latest on R4_19_maintenance
$> git clone -b R4_19_maintenance --recurse-submodules https://git.eclipse.org/r/platform/eclipse.platform.releng.aggregator.git
$> git checkout R4_19_maintenance
$> git submodule foreach R4_19_maintenance
$> git pull --rebase
$> git submodule foreach git pull --rebase

Step 2: do the maven build
$> mvn clean verify -DskipTests=true

The sdk and platform products will be available in 
1. eclipse.platform.releng.aggregator.git/eclipse.platform.releng.tychoeclipsebuilder/sdk/target/products
2. eclipse.platform.releng.aggregator.git/eclipse.platform.releng.tychoeclipsebuilder/platform/target/products
Comment 15 Sravan Kumar Lakkimsetti CLA 2021-04-09 05:42:19 EDT
Verified in Eclipse SDK
Version: 2021-06 (4.20)
Build id: I20210407-1800
OS: Linux, v.5.4.0-70-generic, x86_64 / gtk 3.24.20
Java version: 11.0.10