Enhancing Icon Disabling in Eclipse

[killingerm]

Hello everyone,

I hope you all had a great start to the new year. My name is Manuel, and I am a student supervised by @HeikoKlare and collegue of @Michael5601. It’s exciting to see the significant efforts recently made to enhance the Eclipse platform, particularly through the integration of SVG support to give Eclipse a more modern and polished look.

I would like to initiate a discussion regarding the creation of disabled icons. As it stands, the existing approach is inconsistent across platforms and results in unappealing looking disabled icons. The goal of this discussion is to standardize their appearance, whether pre-designed or dynamically generated at runtime.

How disabled icons are currently created

There are three ways in which a disabled icon can be created, and all of them yield different looking results given the same colored source icon.

1. Pre-generated Icons provided within Eclipse JARs

These are generated via a separate process from the colored icons. Aside from the somewhat dated appearance of eclipse icons as a whole, which is being addressed in this Issue and Community Poll, the process itself could be made obsolete. With the recently introduced SVG support one possible change may be to use filters during runtime rasterization to generate disabled icons as described in this draft.

If they must still be delivered separately, the process may at least be updated to ensure that it produces results identical to the runtime method used in the constructor org.eclipse.swt.graphics.Image(Device, Image, int) with the SWT.IMAGE_DISABLE flag. Currently the produced outputs differ:

This is the result using the Image constructor:

Compared to the pre-designed icon solution:

Here is another example on dark background.

2. Custom disabled icons:

Currently developers have two options to display custom icons in their disabled state:

2.1. Providing their own disabled icons:

The disabling algorithm has no influence here and thus won't be further elaborated.

2.2. Using new Image(Device, Image, int) with the SWT.IMAGE_DISABLE flag:

This method generates a disabled icon from a colored one at runtime. And there are currently two versions of the algorithm, depending on the Operating System in use:

Windows/MacOS:

The algorithm currently in use has not been changed in 16 years and is the main reason for this discussion.

Every pixel is mapped to either one of two grayscale tones depending on the pixels intensity, namely SWT.COLOR_WIDGET_NORMAL_SHADOW and SWT.COLOR_WIDGET_BACKGROUND, and keeps the alpha values. More precisely,

For every Pixel(r, g, b, a) of Image:
r² + g² + b² < 98304 -> return Pixel(display.getSystemColor(SWT.COLOR_WIDGET_NORMAL_SHADOW), a)
else                 -> return Pixel(display.getSystemColor(SWT.COLOR_WIDGET_BACKGROUND), a)  // = invisible

Problem:

• Bright colors are mapped to the background gray, often making them indistinguishable. This wasn’t a problem with older icon styles that used significant shading, but it poses a challenge with modern flat icon designs. Icons without borders and those with predominantly light elements often become partially or completely invisible under this method.
• Gradients and aliasing in the source icon will produce uneven transitions between the gray tones, like this:
  

Linux/GTK+:

The GTK+ variant was modified three years ago to make disabled icons more closely resemble the standard GTK+ disabling.

This change adjusts the implementation of SWT.IMAGE_DISABLE under GTK+,
so that the resulting disabled images are in-line with the GTK+ disabled
look & feel. GTK+ disabled icons retain more detail and color, while
also appearing grayed out.

Bug 575069 - [GTK] Disabled toolbar/button/menu images have poor quality · eclipse-platform/eclipse.platform.swt@2fa3c28

The algorithm halves every pixels RGBA values. The resulting icon appears darker but retains color.

For every Pixel(r, g, b, a) of Image:
return Pixel(Math.round(0.5d * r), Math.round(0.5d * g), Math.round(0.5d * b), Math.round(0.5d * a)

Proposal for Improvement

The inconsistencies between these approaches creates different looking icons, depeding whether the eclipse own proccess, Windows/MacOS or Linux is used. To address this, I propose that a single algorithm should be adopted across all platforms. Two potential approaches are:

1.1. HSB Conversion

Convert RGBA to HSBA, reduce saturation to zero, and slightly decrease brightness (@Michael5601's idea). This method produces visually appealing results. Very dark colors still appear too dark in disabled state, but this could be addressed easily.

1.2. Threshold-Based Grayscale with Additional Tones

This is a modification of the current Win32/macOS algorithm. Introduce a thid grayscale tone and adjust thresholds. The additional gray could be interpolated from SWT.COLOR_WIDGET_NORMAL_SHADOW and SWT.COLOR_WIDGET_BACKGROUND, ensuring the new gray is always somewhere inbetween.

The result is already a lot better looking and the idea can be expanded to 4 or more additional gray tones. If the brightest shade of gray is still kept the same as the background, the problem with disappearing parts of the image will persist in some cases, as can be seen in the example with the speech bubble icon. Also gradients and aliasing in the source icon will still produce uneven transitions between the gray tones.

Example Snippet

I’ve prepared a snippet to demonstrate how the current Image(Device, Image, int) algorithms differ and to experiment with the proposed methods. Choose a folder containing images and adjust the sliders to change the proposed methods parameters. Below is an example output highlighting problematic cases, such as disappearing icons:

Some other things to consider

• Changes will be introduced to all eclipse based IDE. To not break things there should be some option to keep using the old style.

• The community poll showed the new modern style for eclipse icons could be a mono or dual chromatic style. Also the work on theming support has been picked up again. The new algorithm should produce good looking results for these icons.

• If using filters during rasterization is not an option, eclipse icons could still be disabled using the Image constructor, eliminating the separate process and icons would look consistent.

• Perhaps the look of a disabled icon should be influenced by the use of a light or dark theme.

[BeckerWdf]

Here is a small example:

This is the result using the Image constructor:

Compared to the pre-designed icon solution:

Unfortunatelly the images are missing here.

[killingerm]

Thank you for the notice. I've provided new examples.

[Michael5601]

Great post @killingerm, thank you for your effort on this. For the creation of disabled icons with SVGs using a filter at runtime we need a consistent algorithm so the results look the same on all OS.

I will adjust the draft according to the solution that is decided in this discussion. Right now the approach 1.1 HSB Conversion is used in the draft and it looked pretty good in the icons that I tested manually in dark mode.

Please be aware that we also need to consider the SWT.IMAGE_GRAY conversion and not only SWT.IMAGE_DISABLE.

[HeikoKlare]

Thank you for all the investigation, explanation, and the proposed snippet, @killingerm!

First, I would like to summarize what I see as the goal(s) of these efforts (which completely align with the original post):

1. Make explicit provision of disabled icons obsolete (for most cases): most of the currently explicitly provided disabled icons are generated algorithmically and not by manual creation of that icon. That algorithm can be implemented and executed in SWT instead of doing that as a preprocessing step. The algorithm currently implemented in SWT is different from the one applied as preprocessing, which makes that one produce different (worse) results.
2. (Optional:) Unify the algorithm for calculating disabled icons across operating systems.

I would be in favor of simply just doing 1. and discuss whether we want to apply that to GTK as well to also address 2.
One thing that we should think about is whether we want to take over the algorithm as is or whether we want to also apply some improvements to it (probably in configurable way). For example, today's (Windows) applications do not seem to necessarily use gray-scaled icons for showing disablement, but they keep a low saturation. Actually, they also use completely different types of icons, namely only having two colors, no gradients etc., but that way of showing disablement may also be applicable to the existing Eclipse icons.

The algorithm currently applied to the pre-generated icons is defined here:
https://github.com/eclipse-platform/eclipse.platform.images/blob/cd567a18738ebe289f33ce4d124dc8e8808b85d4/org.eclipse.images.renderer/src/main/java/org/eclipse/images/renderer/RenderMojo.java#L318-L334

Without the initial grayscale conversion performed in that algorithm (which we could of course also apply), that algorithm in SWT would (for a single pixel) look something like this:

private RGBA transform(RGBA rgba) {
	float saturation = 0.3f;
	float contrast = 0.2f;
	float brightness = 2.9f;

	// Adjust saturation
	float[] hsba = rgba.getHSBA();
	hsba[1] *= saturation;
	rgba = new RGBA(hsba[0], hsba[1], hsba[2], hsba[3]);

	// Adjust contrast and brightness
	rgba.rgb.blue = (int) (contrast * (rgba.rgb.blue * brightness - 128) + 128);
	rgba.rgb.red= (int) (contrast * (rgba.rgb.red * brightness - 128) + 128);
	rgba.rgb.green = (int) (contrast * (rgba.rgb.green * brightness - 128) + 128);

	return rgba;
}

For testing purposes, I have removed the pre-generated icons in org.eclipse.ui. In the following screenshot, you can see a comparison of the existing, pre-generated disabled icons (at the top) with the icons generated on-the-fly by that algorithm (at the bottom). Note, e.g., the remaining yellow shading inside the redo/undo buttons:

@BeckerWdf what do you think about the approach to integrate a proper (maybe configurable) algorithm for calculating disabled icons on-the-fly in SWT to get rid of (most of) the pre-generated disabled icons in general?

[BeckerWdf]

Would be good to see "inactive" and "active" version of the icon next to each other. And ideally with some Eclipse Icons...

[Michael5601]

Would be good to see "inactive" and "active" version of the icon next to each other. And ideally with some Eclipse Icons...

Here is a comparison for eclipse light and dark mode. On the left side, you can see the default "enabled" icon. On the right, the "disabled" variants are shown, using 80% brightness, 40% alpha, and varying saturation levels of 20%, 50%, and 80%. My favorite is the suggestion of @HeikoKlare with 20% saturation.

[BeckerWdf]

I am fine with 20% or 50% saturation. But I see that the 20% makes is more easy to see that it's disabled because almost all color is gone.

[HeikoKlare]

This is the main menu bar of the Debug perspective in Eclipse. The top one shows the current icons, the buttom one shows the icons disabled by an updated algorithm.

50% saturation, 90% brightness and 40% alpha:

20% saturation, 90% brightness and 40% alpha:

fwiw: I have changed the value of IWorkbenchRegistryConstants#ATT_DISABLEDICON to avoid that the pre-generated disabled icons are loaded.

[BeckerWdf]

so the 20% variant is loser to the current icons. Looks good to me.