SVG rasterization mac is low-resolution

[nedtwigg]

Describe the bug
The new SVG rasterization seems to not be HiDPI on macOS.

To Reproduce

• Before: ImageDescriptor.createFromFile("foo.png") (with a @2x.png available also)
• After: ImageDescriptor.createFromFile("foo.svg") with the new (org.eclipse.swt.svg applied)

Expected behavior
I expected the SVG to render at high-resolution for the mac.

Screenshots

Top row is @2x.png, bottom row is .svg

Environment:

1. Select the platform(s) on which the behavior is seen:

• • All OS
• • Windows
• • Linux
• • macOS

2. Additional OS info (e.g. OS version, Linux Desktop, etc)
   macOS Sequoia 15.5

3. JRE/JDK version
   21

Version since
Eclipse 4.36

[fedejeanne]

cc @HeikoKlare , @Michael5601 .

Is there anything that can be done here? How much influence do we have over the scaling algorithm?

[tmssngr]

I reckon, it needs to be rasterized with doubled (= pixel) scaling.

[HeikoKlare]

I can see the issue also in, e.g., toolbars, of Eclipse products on MacOS. The icons look as if they are upscaled from their 100% version. SVGs are of course rendered in whatever zoom they are needed. I have not seen any issues withthat behavior on Windows so far. So there seems to be a specific bug in how this is handled on MacOS, which means that it's probably an issue of the Image class.

[Phillipus]

Most Macs these days have "retina" displays so hi-dpi x2 is the norm. However, it is possible to have an external x1 dpi display so don't assume it will always be x2.

[HeikoKlare]

I can see the issue also in, e.g., toolbars, of Eclipse products on MacOS. The icons look as if they are upscaled from their 100% version. SVGs are of course rendered in whatever zoom they are needed. I have not seen any issues withthat behavior on Windows so far. So there seems to be a specific bug in how this is handled on MacOS, which means that it's probably an issue of the Image class.

I have to revoke my statement: I took a look at how the icons look in dark theme and they appeared more blurry because of the interpolation with the background. Everything looks fine for me in Eclipse products with a 200% display.

@nedtwigg can you please give us a reproducer? The method ImageDescriptor.createFromFile(String) does not exist, so having a small snippet would be nice.

[nedtwigg]

I'm on an M4 Macbook Air, no external display:

Here is the code that produced the screenshot above

// two-column grid
Layouts.setGrid(parent).numColumns(2);

// “.svg” label + image
Label svgLabel = new Label(parent, SWT.NONE);
svgLabel.setText(".svg");

Label svgImage = new Label(parent, SWT.NONE);
ImageDescriptor svgDesc = ImageDescriptor.createFromFile(
		Issue_2228.class, "/issue_2228/strikethrough.svg");
svgImage.setImage(svgDesc.createImage());

// “.png” label + image
Label pngLabel = new Label(parent, SWT.NONE);
pngLabel.setText(".png");

Label pngImage = new Label(parent, SWT.NONE);
ImageDescriptor pngDesc = ImageDescriptor.createFromFile(
		Issue_2228.class, "/issue_2228/strikethrough.png");
pngImage.setImage(pngDesc.createImage());

And if it's helpful here's that code in an easy-to run test:

• Add SwtKt (and demonstrate that SVG rasterization on mac is low-resolution) diffplug/durian-swt#33

[HeikoKlare]

I have tried to reproduce the issue with the given example on a Mac, but for me the SVG is rendered perfectly fine, just as expected. This is how it looks on a 200% display:

I had to set up a proper the environment for the reproduction on my own since the linked test is not something that can be executed as a standalone JFace snippet/test but requires some additional framework. What I precisely did is to simply execute the following JFace test as JUnit plug-in test. It's not the best way to do it but it's reproducible and easy to set up:

@Test
public void test() {
	final Display display = Display.getDefault();
	Shell shell = new Shell(display);
	createContent(shell);

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

public static void createContent(Composite parent) {
	// two-column grid
	GridLayoutFactory.swtDefaults().numColumns(2).applyTo(parent);

	// “.svg” label + image
	Label svgLabel = new Label(parent, SWT.NONE);
	svgLabel.setText(".svg");

	Label svgImage = new Label(parent, SWT.NONE);
	ImageDescriptor svgDesc = ImageDescriptor.createFromFile(GridLayoutFactoryTest.class, "strikethrough.svg");
	svgImage.setImage(svgDesc.createImage());

	// “.png” label + image
	Label pngLabel = new Label(parent, SWT.NONE);
	pngLabel.setText(".png");

	Label pngImage = new Label(parent, SWT.NONE);
	ImageDescriptor pngDesc = ImageDescriptor.createFromFile(GridLayoutFactoryTest.class, "strikethrough.png");
	pngImage.setImage(pngDesc.createImage());
}

@nedtwigg can you please share a standalone snippet/test requiring pure SWT/JFace to reproduce your issue? Since the issue is not producible with the currently given information (at least for me), I would otherwise close this issue as not reproducible.

[nedtwigg]

JUnit plug-in test

Aha! Maybe that's it. I am not running in an OSGi environment. Perhaps the org.eclipse.swt.svg bundle requires OSGi?

I updated my linked example to have a plain public static void main. You can run it like

• ./gradlew runIssue2228 to run the main
• ./gradlew :durian-swt:interactiveTest --tests Issue_2228 to run the same code as a regular JUnit test (not OSGi Plug-in Test)

[HeikoKlare]

I am not running in an OSGi environment. Perhaps the org.eclipse.swt.svg bundle requires OSGi?

It does not require OSGi by design, but yes, it might be that there is some issue when not using the SVG fragment via OSGi. At least the tests for the rasterizer (in the org.eclipse.swt.tests bundle) are executed in a pure Java environment without OSGi, but they do not test for proper rasterization results at different zooms. However, I don't see why the rasterizer should produce an image at 100% when requested at 200% when not running in an OSGi environment. The only possibility I see is that the JSVG rasterizer is not used at all and instead some Mac-native SVG image loading is used. But I have not seen such a behavior yet (and I have also not seen SVGs being loaded in SWT via native mechanisms on Mac at all).

If you can provide a standalone snippet that can be debugged easily (without any additional framework, gradle etc.) I can have another look at the issue. Without that, unfortunately, I cannot invest additional efforts here.

[nedtwigg]

Here is a standalone snippet that only needs SWT and JFace and these three images. I tried to open a draft PR so that you wouldn't have to copy paste, but the SWT tests folder doesn't have access to JFace. If there is any project you know of which has JFace and regular tests (not Plug-In) I'd be happy to open a draft PR there so that I'm schlepping the image files and not you.

import org.eclipse.jface.layout.GridLayoutFactory;
import org.eclipse.jface.resource.ImageDescriptor;
import org.eclipse.swt.SWT;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.widgets.Shell;

public class Issue_2228 {
	private static void svg_and_png(Composite parent) {
		// two-column grid
		GridLayoutFactory.swtDefaults().numColumns(2).applyTo(parent);

		// “.svg” label + image
		Label svgLabel = new Label(parent, SWT.NONE);
		svgLabel.setText(".svg");

		Label svgImage = new Label(parent, SWT.NONE);
		ImageDescriptor svgDesc = ImageDescriptor.createFromFile(Issue_2228.class, "/issue_2228/strikethrough.svg");
		svgImage.setImage(svgDesc.createImage());

		// “.png” label + image
		Label pngLabel = new Label(parent, SWT.NONE);
		pngLabel.setText(".png");

		Label pngImage = new Label(parent, SWT.NONE);
		ImageDescriptor pngDesc = ImageDescriptor.createFromFile(Issue_2228.class, "/issue_2228/strikethrough.png");
		pngImage.setImage(pngDesc.createImage());
	}

	public static void main(String[] args) {
		Display display = Display.getDefault();
		Shell shell = new Shell(display, SWT.SHELL_TRIM);
		svg_and_png(shell);
		shell.open();
		while (!shell.isDisposed()) {
			if (!display.readAndDispatch()) {
				display.sleep();
			}
		}
		display.dispose();
	}
}

[HeikoKlare]

Yeah, that's basically the test I posted above wrapped into a main method. For just the sake of testing, you could also add a JFace dependency to the SWT tests bundle. In which kind of project did you place that snippet and how did you configure that? Whenever I run anything using SVGs in a non-OSGi environment, the rasterizer is not found by the ServiceLoader. You seem to have some configuration that work.

Exception in thread "main" org.eclipse.swt.SWTException: Unsupported or unrecognized format [No SVG rasterizer found]
	at org.eclipse.swt.SWT.error(SWT.java:4946)
	at org.eclipse.swt.internal.image.SVGFileFormat.loadFromByteStream(SVGFileFormat.java:49)
	at org.eclipse.swt.internal.image.FileFormat.loadFromStream(FileFormat.java:114)
	at org.eclipse.swt.internal.image.FileFormat.load(FileFormat.java:136)
	at org.eclipse.swt.internal.NativeImageLoader.load(NativeImageLoader.java:26)
	at org.eclipse.jface.resource.URLImageDescriptor.loadImageFromStream(URLImageDescriptor.java:152)

[merks]

@HeikoKlare

I was debugging the service loader issue. The problem is that when you have org.eclipse.swt.svg in your workspace and you run standalone, the classpath is like this:

D:\Users\merks\platform-sdk-4.37\git\eclipse.platform.swt\bundles\org.eclipse.swt.svg\bin;

But, the bin folder does not contain the contents of the MANIFEST-INF folder:

If you manually copy it in:

Then the application works because then the service declaration is found:

[HeikoKlare]

Thank you for taking a look, @merks! That's interesting behavior. Now I was able to reproduce the issue and it turns out that the reason is pretty simple: the URLImageDescriptor seems to always return an @2x path when requested for 200%, even if there is no such file (which is particularly the case when having an SVG), so the 100% version is used an upscaled:

The affected line of code is this:
https://github.com/eclipse-platform/eclipse.platform.ui/blob/85ab04202caedb1e501e2d81a86814cd6e60ee80/bundles/org.eclipse.jface/src/org/eclipse/jface/resource/URLImageDescriptor.java#L67

So the issue is somehow similar to:

• Extend existence check in URLImageDescriptor when running without OSGi eclipse.platform.ui#3106

[laeubi]

I was debugging the service loader issue. The problem is that when you have org.eclipse.swt.svg in your workspace and you run standalone, the classpath is like this

Thats a know issue... you can mitigate this by placing the required resources in the root of the source folder (where they are copied to bin then automatically).

I always wanted to fix that for PDE but of course there is so much to do and it was not important enough then :-\

[HeikoKlare]

Turns out that eclipse-platform/eclipse.platform.ui#3106 has just been merged and also fixed this issue. Perfect timing :-)

@nedtwigg can you please retest with the latest state of the eclipse.platform.ui repository (in particular including the fix eclipse-platform/eclipse.platform.ui#3106) and confirm that it fixes your issue?