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

Bug 462952

Summary: [WIN32/GTK] Provide auto-scaling functionality for Icons as per DPI, similar to Mac OS X
Product: [Eclipse Project] Platform Reporter: Sravan Kumar Lakkimsetti <sravankumarl>
Component: SWTAssignee: Sravan Kumar Lakkimsetti <sravankumarl>
Status: VERIFIED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: arunkumar.thondapu, carsten.pfeiffer, christian.albrecht, clint.eastwool, daniel_megert, eclipse, gautier.desaintmartinlacaze, hubert+eclipseorg, johannes, lshanmug, maggu2810, markus.kell.r, mober.at+eclipse, niraj.modi, peter, sascha.appel, sravankumarl, stanio, sven.koehler
Version: 4.5Flags: markus.kell.r: review+
Target Milestone: 4.6 M6   
Hardware: PC   
OS: Linux   
See Also: https://git.eclipse.org/r/56932
Whiteboard:
Bug Depends on: 399786, 488913    
Bug Blocks: 479614    
Attachments:
Description Flags
snippet367 in linux after auto-scaling applied none

Description Sravan Kumar Lakkimsetti CLA 2015-03-24 08:46:11 EDT
This problem is relates to bug 421383.

In case if we do not have higher resolution images for all the icons to render on a high DPI monitor, the UI might look ugly as some are rendered with small size and some with bigger size.

It would be better if we implement a way to resize the image based on dpi if we do not get the higher resolution images. This logic should be implemented only to the images created using the new api introduced in bug 421383
Comment 1 Sravan Kumar Lakkimsetti CLA 2015-05-06 05:28:49 EDT
The basic idea is while rendering the image in GC swt resize the image if the high dpi image is not available. 

Need to explore a method to identify whether the high dpi image is available and resize the image accordingly before rendering.
Comment 2 Markus Keller CLA 2015-05-06 11:19:46 EDT
See bug 399786 comment 8 for a summary of the compatibility issues. I'm not sure the automatic scaling should really be restricted to the new Image constructors. Code that uses the old constructors is already not portable as of today.

I think we first need to decide on a strategy for how to make the high-resolution image contents available to SWT clients. Currently, this is not available on the Mac (and available at the cost of too-small images on Win32/GTK).
Comment 3 Sravan Kumar Lakkimsetti CLA 2015-09-28 04:32:18 EDT
The proposed code changes here are

- Request the high resolution image
- If not available. Get the image for 100% scaling level
- Resize the image to required zoom level. and use it. 
- Restricted to new constructors for now.
Comment 4 Eclipse Genie CLA 2015-09-29 05:58:41 EDT
New Gerrit change created: https://git.eclipse.org/r/56932
Comment 5 Martin Oberhuber CLA 2015-09-29 09:34:31 EDT
(In reply to Sravan Kumar Lakkimsetti from comment #0)
> This logic should be implemented only to the images created using the
> new api introduced in bug 421383

I don't understand that part. IMO, any image provided through the old API
should be treated the same as a "100% only" image provided through the new API.

Rationale: There's always going to be some old plugins around. Unless images of
those plugins are auto-scaled, there would be a mixture of "large" and "small"
toolbar icons for example, causing a huge backward compatibility issue. At least on Windows (looks like on Mac, the OS would do the autoscaling that I request).
CQ:WIND00-WB4-6074
Comment 6 Lakshmi P Shanmugam CLA 2015-10-19 08:10:51 EDT
Hi Sravan,
I believe, you have a patch for autoscaling Images created with old constructors too. Can you please create a gerrit patch for that?
It'll be good if you can post some screenshots on how the images look after autoscaling.
Thanks!

We will also need an API to turn on/off the autoscaling, need to discuss/decide:
- what the API should look like -  
- what should be the default - turned on or off
Comment 7 Sravan Kumar Lakkimsetti CLA 2015-10-19 09:20:13 EDT
Created attachment 257351 [details]
snippet367 in linux after auto-scaling applied
Comment 8 Sravan Kumar Lakkimsetti CLA 2015-12-03 04:50:06 EST
Hi Markus,

This is independent of other hiDPI work. this can be committed independently. Is it possible to complete the review and deliver in M4

Thanks
Sravan
Comment 9 Markus Keller CLA 2015-12-03 05:32:11 EST
I don't think this is independent of the other work, and I wouldn't rush this in now. Such low-level changes in SWT have a high adoption cost, and we should try to minimize the number of breakages for clients. The goal should be to release the whole HiDPI work in the first week of M5. Then we have enough time to polish it and find problems before the milestone.
Comment 11 Sravan Kumar Lakkimsetti CLA 2016-03-18 05:53:07 EDT
verified in I20160317-0200