Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 433098

Summary:	SWT should be able to scale images to match resolution and dpi of display
Product:	[Eclipse Project] Platform	Reporter:	David Williams <david_williams>
Component:	SWT	Assignee:	Platform-SWT-Inbox <platform-swt-inbox>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	eclipse, ericwill, lorenzo.bettini, markus.kell.r, stanio
Version:	4.4	Keywords:	triaged
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:
Bug Depends on:
Bug Blocks:	110035

Description David Williams

2014-04-19 04:23:27 EDT

This has been discussed before, in bug 110035, which was kicked back to UI with the statement -- from Steve Northover, of all people ... that's how old the issue is :) -- that "This is a UI problem, not SWT.  We will display the icons we are given."

But I don't think that suffices ... you'd have to be given a nearly infinite number of icons which seems impractical. 

I'm opening this now, since I think the problem is only going to get worse, as displays and resolutions are one of the rapidly changing areas in "end user" computing, and the demands of "Graphical User interfaces" will only get higher. 

Not to mention, I've seen a good example of this recently with our "Luna icons". 

On windows, if the resolution is set at 100% (96 dpi) then Windows Explorer picks the "blue and white" 16x16 icons to display next to the eclipse.exe file. And, naturally, so does our "SDK app". 

But, if I change the resolution to 125% or 150% then windows decides it needs a larger icon and, I assume, is "scaling down" one of the larger icons we provide, and it shows up as orange, blue and white. The smallest "orange blue and while" icon we provide is 32x32 ... so I'd assume it's scaling down that one ... but, I don't really know how it works, under the hood. And, as I understand it, there are ways people can specify even "custom" dpi's, (somewhere) so seems at some point, SWT would be responsible for being aware of the resolution and dpi and selecting and scaling the right icon ... to at least match what ever the operating system is doing. (Or, ideally, there is an Operating System API that would "do it for you"). 

If there is more the UI can do to "help" accommodate these scenarios, then let us know ... but, somehow don't think it'd be able to be handled completely by the "UI layer".

Comment 1 Markus Keller

2014-04-19 17:37:51 EDT

Not sure if this should be a separate bug or just a dup of bug 382972.

SWT should not try to implement resolution-independent images itself, but it should reuse / offer APIs for what's already offered by the operating systems / native windowing toolkits.

Comment 2 David Williams

2014-04-19 22:52:47 EDT

(In reply to Markus Keller from comment #1)

> SWT should not try to implement resolution-independent images itself, but it
> should reuse / offer APIs for what's already offered by the operating
> systems / native windowing toolkits.

As always, Markus says it well. 

FWIW, I've learned (from "experience") that Windows is rescaling based on what's in the ICO file ... SWT is rescaling based on what's in the "windowsImages" list ... does that sound right? 

While typically these are the same, a mistake in Saturday afternoon's build made this apparent ... where images in ICO file were changed, the images making up "windowsImages" were not, just as an oversite. 

I'm assuming it's still SWT that has "whole list" and picks which one to scale. 
Is that that a correct assumption? Or does the UI layer do that? 

If SWT does have "whole list", does order matter? I know in ICO file the images are indexed in order of 48 being first, then 32, then 16 ... 

But in "windowsImages" list, they are ordered as "16, 32, 48". 

Just providing more data, in case it helps. 

Thanks.

Comment 3 Eric Williams

2019-02-01 14:12:51 EST

This has been addressed in the HiDPI port(s).