Skip to content

A strict check 200% image data is double the size of 100% image data #2249

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

arunjose696
Copy link
Contributor

@arunjose696 arunjose696 commented Jun 18, 2025

A strict check to be used only for debugging means, this ensures the imageData is scaled linearly for 100 and 200 zooms.

Steps to reproduce

Out of the blow snippets. Snippet1 which uses an image data provider that always returns the same image, when executed with the VM argument -Dorg.eclipse.swt.internal.enableStrictChecks=True, logs the error` "ImageData should be linearly scaled across zooms." to stdout. Whereas snippet 2 which scales ImageData linearly runs without this error log.

snippet 1
package org.eclipse.swt.snippets;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.widgets.*;
public class TestImageProvider {
    public static void main(String[] args) {
        Display display = new Display();
        ImageDataProvider provider = (zoom) -> new ImageData(
            16, 16, 32,
            new PaletteData((new RGB(255, 0, 0)))
        );
        Image image = new Image(display, provider);
        System.out.println("Done execution");
    }
}
snippet 2
package org.eclipse.swt.snippets;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.widgets.*;
public class TestImageProvider {
    public static void main(String[] args) {
        Display display = new Display();
        ImageDataProvider provider = (zoom) -> new ImageData(
            16*zoom/100, 16*zoom/100, 32,
            new PaletteData((new RGB(255, 0, 0)))
        );
        Image image = new Image(display, provider);  
        System.out.println("Done execution");
    }
}

The below examples demonstrate testing this again with PNG images. In the first snippet, the ImageDataProvider returns the image data from the same file for both 100% and 200% zoom levels without scaling, which causes the error message "ImageData should be linearly scaled across zooms." to be printed to stdout. In the second snippet it provides properly scaled image data at 200% zoom (using a scaled image), so it executes without logging this error.
To run these snippets, download the following PNG files and place them in your working directory:
pause.png

[email protected]

snippet 1
package org.eclipse.swt.snippets;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.widgets.*;
public class TestImageProvider {
    public static void main(String[] args) {
    	System.out.println("Working directory: " + System.getProperty("user.dir"));
        Display display = new Display();

        ImageDataProvider provider = zoom -> {
            if (zoom == 100) {
                return new ImageData("pause.png");
            }
            else if (zoom == 200) {
                return new ImageData("pause.png");
            }
            else {
                return null;
            }
        };

        Image image = new Image(display, provider);
        System.out.println("Done execution");
    }
}
snippet 2
package org.eclipse.swt.snippets;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.widgets.*;
public class TestImageProvider {
    public static void main(String[] args) {
    	System.out.println("Working directory: " + System.getProperty("user.dir"));
        Display display = new Display();

        ImageDataProvider provider = zoom -> {
            if (zoom == 100) {
                return new ImageData("pause.png");
            }
            else if (zoom == 200) {
                return new ImageData("[email protected]");
            }
            else {
                return null;
            }
        };

        Image image = new Image(display, provider);
        System.out.println("Done execution");
    }
}

Copy link
Contributor

github-actions bot commented Jun 18, 2025

Test Results

   546 files  ±0     546 suites  ±0   29m 59s ⏱️ + 3m 2s
 4 412 tests ±0   4 395 ✅ ±0   17 💤 ±0  0 ❌ ±0 
16 718 runs  ±0  16 591 ✅ ±0  127 💤 ±0  0 ❌ ±0 

Results for commit 34e4127. ± Comparison against base commit 34a4d76.

♻️ This comment has been updated with latest results.

@arunjose696 arunjose696 force-pushed the arunjose696/313/StrictCheck branch from 085c1c6 to d78d6ae Compare June 23, 2025 11:33
@arunjose696 arunjose696 force-pushed the arunjose696/313/StrictCheck branch 2 times, most recently from db68f87 to 1403084 Compare July 1, 2025 09:55
@arunjose696
Copy link
Contributor Author

In CI failing checks I have the below error, Dont think this has anything to do with my changes.

[2025-07-01T10:06:14.756Z] [ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:5.0.0-SNAPSHOT:compare-version-with-baselines (compare-attached-artifacts-with-release) on project org.eclipse.swt.tools: Baseline and reactor have the same fully qualified version, but different content
[2025-07-01T10:06:14.756Z] [ERROR] different
[2025-07-01T10:06:14.756Z] [ERROR]    META-INF/ECLIPSE_.RSA: present in baseline only
[2025-07-01T10:06:14.756Z] [ERROR]    META-INF/ECLIPSE_.SF: present in baseline only
[2025-07-01T10:06:14.756Z] [ERROR] -> [Help 1]
[2025-07-01T10:06:14.756Z] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:5.0.0-SNAPSHOT:compare-version-with-baselines (compare-attached-artifacts-with-release) on project org.eclipse.swt.tools: Baseline and reactor have the same fully qualified version, but different content
[2025-07-01T10:06:14.756Z] different
[2025-07-01T10:06:14.756Z]    META-INF/ECLIPSE_.RSA: present in baseline only
[2025-07-01T10:06:14.756Z]    META-INF/ECLIPSE_.SF: present in baseline only

Copy link
Contributor

@fedejeanne fedejeanne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments before I move to the testing phase

@arunjose696 arunjose696 force-pushed the arunjose696/313/StrictCheck branch 3 times, most recently from 8b2a4c3 to 73e1a6c Compare July 3, 2025 15:24
@fedejeanne fedejeanne force-pushed the arunjose696/313/StrictCheck branch 2 times, most recently from 982ab6d to a6d4f74 Compare July 4, 2025 10:05
@arunjose696 arunjose696 force-pushed the arunjose696/313/StrictCheck branch 5 times, most recently from bc5eaca to c40fee2 Compare July 4, 2025 11:47
Copy link
Contributor

@HeikoKlare HeikoKlare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, the PR looks good to me. I have only one comment regarding the printed message.

@arunjose696 arunjose696 force-pushed the arunjose696/313/StrictCheck branch 2 times, most recently from 9f23866 to 5a064b6 Compare July 22, 2025 13:42
@HeikoKlare HeikoKlare force-pushed the arunjose696/313/StrictCheck branch from 5a064b6 to e06a13e Compare July 22, 2025 15:20
A strict check to be used only for debugging means, which ensures the
imageData returned by an ImageDataProvider is scaled linearly for 100
and 200 zooms.
@HeikoKlare HeikoKlare force-pushed the arunjose696/313/StrictCheck branch from e06a13e to 34e4127 Compare July 22, 2025 15:20
Copy link
Contributor

@HeikoKlare HeikoKlare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine now. I rebased on master and slightly enhanced the information in the message (including the image data sizes at 100%/200%).

@HeikoKlare HeikoKlare merged commit 216f1ad into eclipse-platform:master Jul 22, 2025
17 checks passed
@HeikoKlare HeikoKlare deleted the arunjose696/313/StrictCheck branch July 22, 2025 15:41
@ptziegler
Copy link
Contributor

This caused a regression when working with swt.autoScale. See #2353

arunjose696 added a commit to vi-eclipse/eclipse.platform.swt that referenced this pull request Jul 30, 2025
ImageDataProvider zoom handling

In PR eclipse-platform#2249, a strict check was introduced  that ImageData should be
linearly scaled for other zoom levels. And imageDataProviders in SWT
repo not following this strict checks were modified (eg to return only
imageData at 100%).

However, this change broke DPIUtil.autoScaleImageData. That function
creates an Image using the system zoom level, draws it on a GC at scaled
dimensions, and then requests ImageData at 100% zoom from the image.
Since the ImageDataProvider was now restricted to 100% zoom only,
requesting imageData at other zoom levels while creating an image at
system zoom level triggered recursive calls,  causing a stack overflow
error.

The current commit reverts the behavior of the ImageDataProvider used in
DPIUtil.autoScaleImageData to return the same ImageData at all zoom
levels.
We also Disable the strict zoom check in this specific case, because the
scaling is done by GC.drawImage() and the ImageData used to create the
is expected to be same.
arunjose696 added a commit to vi-eclipse/eclipse.platform.swt that referenced this pull request Jul 30, 2025
ImageDataProvider zoom handling

In PR eclipse-platform#2249, a strict check was introduced  that ImageData should be
linearly scaled for other zoom levels. And imageDataProviders in SWT
repo not following this strict checks were modified (eg to return only
imageData at 100%).

However, this change broke DPIUtil.autoScaleImageData. That function
creates an Image using the system zoom level, draws it on a GC at scaled
dimensions, and then requests ImageData at 100% zoom from the image.
Since the ImageDataProvider was now restricted to 100% zoom only,
requesting imageData at other zoom levels while creating an image at
system zoom level triggered recursive calls,  causing a stack overflow
error.

The current commit reverts the behavior of the ImageDataProvider used in
DPIUtil.autoScaleImageData to return the same ImageData at all zoom
levels.
We also Disable the strict zoom check in this specific case, because the
scaling is done by GC.drawImage() and the ImageData used to create the
is expected to be same.
arunjose696 added a commit to vi-eclipse/eclipse.platform.swt that referenced this pull request Jul 30, 2025
In PR eclipse-platform#2249, a strict check was introduced  that ImageData should be
linearly scaled for other zoom levels. And imageDataProviders in SWT
repo not following this strict checks were modified (eg to return only
imageData at 100%).

However, this change broke DPIUtil.autoScaleImageData. That function
creates an Image using the system zoom level, draws it on a GC at scaled
dimensions, and then requests ImageData at 100% zoom from the image.
Since the ImageDataProvider was now restricted to 100% zoom only,
requesting imageData at other zoom levels while creating an image at
system zoom level triggered recursive calls,  causing a stack overflow
error.

The current commit reverts the behavior of the ImageDataProvider used in
DPIUtil.autoScaleImageData to return the same ImageData at all zoom
levels.
We also Disable the strict zoom check in this specific case, because the
scaling is done by GC.drawImage() and the ImageData used to create the
is expected to be same.
arunjose696 added a commit to vi-eclipse/eclipse.platform.swt that referenced this pull request Jul 30, 2025
In PR eclipse-platform#2249, a strict check was introduced  that ImageData should be
linearly scaled for other zoom levels. And imageDataProviders in SWT
repo not following this strict checks were modified (eg to return only
imageData at 100%).

However, this change broke DPIUtil.autoScaleImageData. That function
creates an Image using the system zoom level, draws it on a GC at scaled
dimensions, and then requests ImageData at 100% zoom from the image.
Since the ImageDataProvider was now restricted to 100% zoom only,
requesting imageData at other zoom levels while creating an image at
system zoom level triggered recursive calls,  causing a stack overflow
error.

The current commit reverts the behavior of the ImageDataProvider used in
DPIUtil.autoScaleImageData to return the same ImageData at all zoom
levels.
We also Disable the strict zoom check in this specific case, because the
scaling is done by GC.drawImage() and the ImageData used to create the
is expected to be same.
arunjose696 added a commit to vi-eclipse/eclipse.platform.swt that referenced this pull request Jul 30, 2025
In PR eclipse-platform#2249, a strict check was introduced  that ImageData should be
linearly scaled for other zoom levels. And imageDataProviders in SWT
repo not following this strict checks were modified (eg to return only
imageData at 100%).

However, this change broke DPIUtil.autoScaleImageData. That function
creates an Image using the system zoom level, draws it on a GC at scaled
dimensions, and then requests ImageData at 100% zoom from the image.
Since the ImageDataProvider was now restricted to 100% zoom only,
requesting imageData at other zoom levels while creating an image at
system zoom level triggered recursive calls,  causing a stack overflow
error.

The current commit reverts the behavior of the ImageDataProvider used in
DPIUtil.autoScaleImageData to return the same ImageData at all zoom
levels.
We also Disable the strict zoom check in this specific case, because the
scaling is done by GC.drawImage() and the ImageData used to create the
is expected to be same.
arunjose696 added a commit to vi-eclipse/eclipse.platform.swt that referenced this pull request Jul 30, 2025
In PR eclipse-platform#2249, a strict check was introduced  that ImageData should be
linearly scaled for other zoom levels. And imageDataProviders in SWT
repo not following this strict checks were modified (eg to return only
imageData at 100%).

However, this change broke DPIUtil.autoScaleImageData. That function
creates an Image using the system zoom level, draws it on a GC at scaled
dimensions, and then requests ImageData at 100% zoom from the image.
Since the ImageDataProvider was now restricted to 100% zoom only,
requesting imageData at other zoom levels while creating an image at
system zoom level triggered recursive calls,  causing a stack overflow
error.

The current commit reverts the behavior of the ImageDataProvider used in
DPIUtil.autoScaleImageData to return the same ImageData at all zoom
levels.
We also Disable the strict zoom check in this specific case, because the
scaling is done by GC.drawImage() and the ImageData used to create the
is expected to be same.
arunjose696 added a commit to vi-eclipse/eclipse.platform.swt that referenced this pull request Jul 30, 2025
In PR eclipse-platform#2249, a strict check was introduced  that ImageData should be
linearly scaled for other zoom levels. And imageDataProviders in SWT
repo not following this strict checks were modified (eg to return only
imageData at 100%).

However, this change broke DPIUtil.autoScaleImageData. That function
creates an Image using the system zoom level, draws it on a GC at scaled
dimensions, and then requests ImageData at 100% zoom from the image.
Since the ImageDataProvider was now restricted to 100% zoom only,
requesting imageData at other zoom levels while creating an image at
system zoom level triggered recursive calls,  causing a stack overflow
error.

The current commit reverts the behavior of the ImageDataProvider used in
DPIUtil.autoScaleImageData to return the same ImageData at all zoom
levels.
We also Disable the strict zoom check in this specific case, because the
scaling is done by GC.drawImage() and the ImageData used to create the
is expected to be same.
arunjose696 added a commit to vi-eclipse/eclipse.platform.swt that referenced this pull request Jul 30, 2025
In PR eclipse-platform#2249, a strict check was introduced  that ImageData should be
linearly scaled for other zoom levels. And imageDataProviders in SWT
repo not following this strict checks were modified (eg to return only
imageData at 100%).

However, this change broke DPIUtil.autoScaleImageData. That function
creates an Image using the system zoom level, draws it on a GC at scaled
dimensions, and then requests ImageData at 100% zoom from the image.
Since the ImageDataProvider was now restricted to 100% zoom only,
requesting imageData at other zoom levels while creating an image at
system zoom level triggered recursive calls,  causing a stack overflow
error.

The current commit reverts the behavior of the ImageDataProvider used in
DPIUtil.autoScaleImageData to return the same ImageData at all zoom
levels.
We also Disable the strict zoom check in this specific case, because the
scaling is done by GC.drawImage() and the ImageData used to create the
is expected to be same.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Resilient handling of Images with non-linearly-scaled ImageData
6 participants