Skip to content

Make SVG currentColor configurable - #3552

Draft
vogella wants to merge 1 commit into
eclipse-platform:masterfrom
vogella:svg-current-color
Draft

Make SVG currentColor configurable#3552
vogella wants to merge 1 commit into
eclipse-platform:masterfrom
vogella:svg-current-color

Conversation

@vogella

@vogella vogella commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

SVG icons using fill="currentColor" are rasterized with a hardcoded color in JSVGRasterizer. Until 2026-06 that was white (the AWT Graphics2D default), since 2026-09 it is black. Either default is wrong for one of the themes, so the color must be configurable to support both dark and light themes.

Adds a global current color, settable via JSVGRasterizer.setCurrentColor(RGB) or the system property swt.svg.currentColor (e.g. #FFFFFF). Default stays black; only currentColor references are affected, explicit fills are untouched. Images already rasterized keep their color.

Intended consumer is the platform CSS/theme engine, which can push the theme color before the workbench renders its icons.

@eclipse-platform-bot

eclipse-platform-bot commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

bundles/org.eclipse.swt.svg/META-INF/MANIFEST.MF
bundles/org.eclipse.swt.svg/pom.xml

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch
From 35bfec5274080d7dd22124b5073e3704b49a6a91 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Wed, 2 Sep 2026 09:39:45 +0000
Subject: [PATCH] Version bump(s) for 4.42 stream


diff --git a/bundles/org.eclipse.swt.svg/META-INF/MANIFEST.MF b/bundles/org.eclipse.swt.svg/META-INF/MANIFEST.MF
index f51e06d1b8..4d0bdc9a1e 100644
--- a/bundles/org.eclipse.swt.svg/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.swt.svg/META-INF/MANIFEST.MF
@@ -1,7 +1,7 @@
 Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-SymbolicName: org.eclipse.swt.svg
-Bundle-Version: 3.133.100.qualifier
+Bundle-Version: 3.133.200.qualifier
 Automatic-Module-Name: org.eclipse.swt.svg
 Bundle-Name: %fragmentName
 Bundle-Vendor: %providerName
diff --git a/bundles/org.eclipse.swt.svg/pom.xml b/bundles/org.eclipse.swt.svg/pom.xml
index 19bc72ffa7..d52e487d3f 100644
--- a/bundles/org.eclipse.swt.svg/pom.xml
+++ b/bundles/org.eclipse.swt.svg/pom.xml
@@ -19,7 +19,7 @@
 		<relativePath>../../</relativePath>
 	</parent>
 	<artifactId>org.eclipse.swt.svg</artifactId>
-	<version>3.133.100-SNAPSHOT</version>
+	<version>3.133.200-SNAPSHOT</version>
 	<packaging>eclipse-plugin</packaging>
 	<properties>
 		<tycho.extraClasspathJars>IGNORE</tycho.extraClasspathJars>
-- 
2.55.0

Further information are available in Common Build Issues - Missing version increments.

@github-actions

github-actions Bot commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Test Results

  212 files  ± 0    212 suites  ±0   28m 51s ⏱️ + 2m 28s
4 936 tests + 3  4 910 ✅ + 3   26 💤 ±0  0 ❌ ±0 
7 139 runs  +18  6 959 ✅ +18  180 💤 ±0  0 ❌ ±0 

Results for commit 817f0a4. ± Comparison against base commit 38d2d76.

♻️ This comment has been updated with latest results.

@BeckerWdf

Copy link
Copy Markdown
Member

So what is "currentColor" used for? The background of the image?
All the dual tone icons have a transparent background color.
I am not aware that Jasmins style guide defines some "currentColor" but it specifies a base colors (grey-ish) and multiple accent colors (red, orange, blue, green) and afaik these are independent from "light" or "dark" theme.

See:
image

Can you pls. explain

@vogella

vogella commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

currentColor

SVG allows to use "currentColor" as color. Part of the spec.

If you use acurrentColor in your SVG files, SWT hard-codes this to BLACK in 2026-09 and WHITE in 2026-06. With this change, we could configure the target color.

Your icons need no change. The change gives you the option to switch to "currentColor". Change would be easy, search and replace. You could set grey-isch as default or use different colors.

In short, with this change you gain flexility for the color. If not desired you do not have to change anything.

@HeikoKlare

Copy link
Copy Markdown
Contributor

If you use acurrentColor in your SVG files, SWT hard-codes this to BLACK in 2026-09 and WHITE in 2026-06.

This statement contradicts the findings that led to the change in 2026-09, as it was supposed to preserve pre-existing behavior rather than changing it:

How can we reproduce the assumed currentColor change between 2026-06 and 2026-09?

@BeckerWdf

Copy link
Copy Markdown
Member

currentColor

SVG allows to use "currentColor" as color. Part of the spec.

If you use acurrentColor in your SVG files, SWT hard-codes this to BLACK in 2026-09 and WHITE in 2026-06. With this change, we could configure the target color.

Your icons need no change. The change gives you the option to switch to "currentColor". Change would be easy, search and replace. You could set grey-isch as default or use different colors.

In short, with this change you gain flexility for the color. If not desired you do not have to change anything.

ok understood. Do we have any concrete SVGs in Platform or other products that use the "currentColor" and currently have issues with the current implementation?

Is there a way in the SVG spec to define additional colors (next to currentColor)? If that would be possible we could also "externalize" also the definition of the accent colors

@vogella

vogella commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

If you use acurrentColor in your SVG files, SWT hard-codes this to BLACK in 2026-09 and WHITE in 2026-06.

How can we reproduce the assumed currentColor change between 2026-06 and 2026-09?

Create a Eclipse RCP with a template add a svg file to its toolbar using currentColor and run it against a target platform with 2026-06 and afterwards 2026-09.

IMHO BLACK is the better default for curentColor so the 2026-09 change is an improvement.

@vogella

vogella commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

ok understood. Do we have any concrete SVGs in Platform or other products that use the "currentColor" and currently have issues with the current implementation?

No, I discovered that working for a RCP client. AFAIK all platform svg use fixed colors.

Is there a way in the SVG spec to define additional colors (next to currentColor)? If that would be possible we could also "externalize" also the definition of the accent colors

I don't know.

SVG icons using fill="currentColor" are rasterized with a hardcoded color in
JSVGRasterizer. Until 2026-06 that was white (the AWT default), since 2026-09
it is black. Either default is wrong for one of the themes, so the color must
be configurable to support both dark and light themes.

Add a global current color, settable via JSVGRasterizer.setCurrentColor(RGB)
or the system property swt.svg.currentColor. Default stays black and explicit
fills are unaffected.

Assisted-by: multiple AI agents and layers of automated tooling 🤖
@HeikoKlare

Copy link
Copy Markdown
Contributor

IMHO BLACK is the better default for curentColor so the 2026-09 change is an improvement.

It used to be the default before as well. 2026-06 just had the regression from the change in the JSVG implementation.

Regarding the actual PR I have some questions/comments: the configuration is static, which means that you are limited to sharing the same currentColor for all images being rasterized. That may or may not be reasonable but should be explicitly discussed. How would a usage pattern of this look like? Since the JSVGRasterizer is just one possible rasterizer implementation, requiring the user to call setCurrentColor() on that specific implementation or setting a (SWT-scoped) system property that is specifically evaluated in that rasterizer is questionable. Shouldn't that be global SWT setting than that is passed to whatever concrete rasterizer is available?
In addition, you would be able to set that value from whatever thread you want and you can trigger image rasterization from at least every display thread, but the implementation does not implement any required memory barriers for introducing an according happend-before relation. That's at least a slight risk for seldom race conditions leading to unexpected rendering results.

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.

4 participants