Sharp rendering of SVGs passed as InputStream #2935

ShahzaibIbrahim · 2026-01-07T11:03:30Z

Storing input stream content to be later used for executeOnImageHandleAtBestFittingSize() to sharply render the svg images when created using Image(Display, InputStream)

In addition, on Linux an image can be refreshed for a new zoom (Image#refreshImageForZoom()), which was also not supported for the case that the image is based on an InputStream. Since we are storing the input stream content anyway, this case is should be covered here too.

Contribute to: #2917

How to Test

Run this Snippet on Windows, Mac and Linux and compare the results:

package org.eclipse.swt.snippets;
import java.nio.file.Path;

import org.eclipse.swt.graphics.*;
import org.eclipse.swt.layout.*;
import org.eclipse.swt.widgets.*;

public class SVGImageTests {

    public static void main(String[] args) throws Exception {
        final Display display = new Display();

        final Shell shell = new Shell(display);
        shell.setText("SVG Image Test");
        shell.setLayout(new FillLayout());
        shell.setBounds(250, 50, 1000, 400);
        shell.setBackground(new Color(255, 255, 255));

        String imgPath = "eclipse16.svg";
        Path fullPath = Path.of(SVGImageTests.class.getResource(imgPath).toURI());

        // Image loaded in stream
        Image image1 = new Image(display, SVGImageTests.class.getResourceAsStream(imgPath));

        // Image loaded in ImageFileNameProvider
        Image image3 = new Image(display, (ImageFileNameProvider) zoom -> {
            return zoom == 100 ? fullPath.toString() : null;
        });

        shell.addPaintListener(e -> {
            e.gc.drawImage(image1, 20, 10, 300, 300);
            e.gc.drawText("Image(Display, InputStream)", 80, 300);

            e.gc.drawImage(image3, 340, 10, 300, 300);
            e.gc.drawText("Image(Display, String)", 420, 300);
        });

        shell.open();

        while(!shell.isDisposed()) {
            if(!display.readAndDispatch()) {
                display.sleep();
            }
        }

        display.dispose();
    }
}

Use this SVG image for the Snippet:

Currently, In GTK and Cocoa, an image based on an SVG passed as inputStream to Image(Device, InputStream) was blurry. With the current change it should look as good as ImageFileNameProvider as shown in snippet.

Results

Without this PR:

After Changes:

GTK:

Cocoa:

To be Tested

github-actions · 2026-01-07T11:18:54Z

Test Results

176 files ±0 176 suites ±0 26m 57s ⏱️ - 2m 13s
4 676 tests ±0 4 654 ✅ ±0 22 💤 ±0 0 ❌ ±0
482 runs ±0 476 ✅ ±0 6 💤 ±0 0 ❌ ±0

Results for commit 4cdd05f. ± Comparison against base commit bbb21e5.

♻️ This comment has been updated with latest results.

laeubi · 2026-01-07T11:24:45Z

@ShahzaibIbrahim please provide a consistent PR description and at best show before/after screenshot.
Also commit descriptions seem not sufficient.

ShahzaibIbrahim · 2026-01-07T12:10:10Z

@ShahzaibIbrahim please provide a consistent PR description and at best show before/after screenshot. Also commit descriptions seem not sufficient.

Hi @laeubi, This PR is not ready and hence it's currently drafted.

laeubi · 2026-01-07T12:22:59Z

@ShahzaibIbrahim please provide a consistent PR description and at best show before/after screenshot. Also commit descriptions seem not sufficient.

Hi @laeubi, This PR is not ready and hence it's currently drafted.

I appreciate that it's marked as a draft, but even draft PRs should contain a clear title and meaningful description explaining what you're working on and what the expected outcome is. This helps maintainers understand the context and provide better guidance early in the process.

The SWT repository should have draft PRs that clearly communicate:

What issue or improvement you're addressing
What approach you're taking
What the current state is and what still needs to be done

If you need to run CI checks while developing, you can do that on your fork as well. Please update the PR description before continuing, so we can provide better feedback. Thanks!

ShahzaibIbrahim · 2026-01-07T12:37:13Z

I appreciate that it's marked as a draft, but even draft PRs should contain a clear title and meaningful description explaining what you're working on and what the expected outcome is. This helps maintainers understand the context and provide better guidance early in the process.

The SWT repository should have draft PRs that clearly communicate:

What issue or improvement you're addressing

What approach you're taking

What the current state is and what still needs to be done

I have updated the PR description with all the sufficient information I currently have.

laeubi · 2026-01-07T12:54:24Z

bundles/org.eclipse.swt/Eclipse SWT/cocoa/org/eclipse/swt/graphics/Image.java

+	/**
+	 * Byte array to store input stream data to draw on various Zoom levels
+	 */
+	private byte[] inputStreamData;


Would this not better be part of a supplier instead of part of the image?

I need o make it part of Image class because I have to use it in private class CachedImageAtSize#loadImageDataAtExactSize not just in initWithSupplier. Or do you mean something else?

Phillipus · 2026-01-07T14:17:15Z

Some early feedback on Mac for this one...

Here's a screenshot running this Snippet of the changes in this PR and #2924

@ShahzaibIbrahim Thank-you for your work on this and #2924

ShahzaibIbrahim · 2026-01-09T12:53:07Z

@HeikoKlare I think tests are fixed. Can you please test my snippet on multiple zoom level on mac to mark this PR ready for review?

Storing input stream content to be later used for executeOnImageHandleAtBestFittingSize() to sharply render the svg images when created using Image(Display, InputStream)

Phillipus · 2026-01-09T17:10:45Z

Mac with latest changes:

HeikoKlare

Following up on the comment of @laeubi, wouldn't it be cleaner to wrap the input stream handling in an ImageDataProvider to not further mess up the Image implementation with mutual exclusive providers?
It might work as follows (starting from the InputStream constructor):

Read stream data from stream
Check if stream data belong to a dynamically sizable image, in that case create an ImageDataAtSizeProvider otherwise create an ImageDataProvider.
- The ImageDataAtSizeProvider will store the stream data and return accordingly loaded image data in its getImageData(width, height) and getImageData(zoom) methods
- The ImageDataProvider will only return according image data at 100% and none for the other zoom, so it does not need to store the stream data

Nothing needs to be changed for the loadImageDataAtExactSize then, as it reuses the ImageDataAtSizeProvider functionality.

HeikoKlare · 2026-01-10T08:15:53Z

bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/graphics/Image.java

+		initDataFromInputStream(currentDeviceZoom);
+		init();
+	} catch (IOException e) {
+		SWT.error(SWT.ERROR_INVALID_ARGUMENT, e);


This is not the correct error w.r.t. the contract. It should be SWT.ERROR_IO.

HeikoKlare · 2026-01-10T08:17:14Z

bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/graphics/Image.java

 		}
+	} else if (inputStreamData != null) {
+		int deviceZoomLevel = deviceZoom;
+		if (deviceZoomLevel != currentDeviceZoom) {


One could think of checking for isDynamicallySizable here, as otherwise you will unnecessary destroy and recreate the exact same handle. However, it's not done for the other providers as well and with my general remark, this will not be easily possible either.

HeikoKlare · 2026-01-10T08:18:34Z

examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/SVGImageTests.java

+import org.eclipse.swt.layout.*;
+import org.eclipse.swt.widgets.*;
+
+public class SVGImageTests {


There is already Snippet390, so this one is obsolete.

HeikoKlare · 2026-01-10T08:20:02Z

bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/graphics/Image.java

 	private ImageGcDrawer imageGcDrawer;

+	/**
+	 * Byte array to store input stream data to draw on various Zoom levels


There is no drawing happening with input streams (same for the Cocoa implementation).

Suggested change

* Byte array to store input stream data to draw on various Zoom levels

* Byte array to store input stream data to convert into image data at various Zoom levels

ShahzaibIbrahim force-pushed the master-567 branch from 9d99069 to 3f0b54c Compare January 7, 2026 12:24

ShahzaibIbrahim linked an issue Jan 7, 2026 that may be closed by this pull request

Sharp rendering of SVGs passed as InputStream to Image constructor when drawing at arbitrary size vi-eclipse/Eclipse-Platform#567

Open

ShahzaibIbrahim changed the title ~~SVG Sharp Renderring~~ Sharp rendering of SVGs passed as InputStream Jan 7, 2026

laeubi reviewed Jan 7, 2026

View reviewed changes

ShahzaibIbrahim force-pushed the master-567 branch 2 times, most recently from 25abe2b to e4cd2a2 Compare January 8, 2026 12:55

ShahzaibIbrahim added 2 commits January 9, 2026 13:53

Sharp rendering of SVGs passed as InputStream

d1a7d32

Storing input stream content to be later used for executeOnImageHandleAtBestFittingSize() to sharply render the svg images when created using Image(Display, InputStream)

Test failure fix

4cdd05f

ShahzaibIbrahim force-pushed the master-567 branch from e4cd2a2 to 4cdd05f Compare January 9, 2026 12:53

HeikoKlare reviewed Jan 10, 2026

View reviewed changes

	* Byte array to store input stream data to draw on various Zoom levels
	* Byte array to store input stream data to convert into image data at various Zoom levels

Sharp rendering of SVGs passed as InputStream #2935

Are you sure you want to change the base?

Sharp rendering of SVGs passed as InputStream #2935

Conversation

ShahzaibIbrahim commented Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

How to Test

Results

Uh oh!

github-actions bot commented Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

laeubi commented Jan 7, 2026

Uh oh!

ShahzaibIbrahim commented Jan 7, 2026

Uh oh!

laeubi commented Jan 7, 2026

Uh oh!

ShahzaibIbrahim commented Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

laeubi Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

ShahzaibIbrahim Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Phillipus commented Jan 7, 2026

Uh oh!

ShahzaibIbrahim commented Jan 9, 2026

Uh oh!

Phillipus commented Jan 9, 2026

Uh oh!

HeikoKlare left a comment

Choose a reason for hiding this comment

Uh oh!

HeikoKlare Jan 10, 2026

Choose a reason for hiding this comment

Uh oh!

HeikoKlare Jan 10, 2026

Choose a reason for hiding this comment

Uh oh!

HeikoKlare Jan 10, 2026

Choose a reason for hiding this comment

Uh oh!

HeikoKlare Jan 10, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ShahzaibIbrahim commented Jan 7, 2026 •

edited

Loading

github-actions bot commented Jan 7, 2026 •

edited

Loading

ShahzaibIbrahim commented Jan 7, 2026 •

edited

Loading