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

Bug 498062

Summary: [HiDPI] autoScale wrongly applies to Printer devices on Windows
Product: [Eclipse Project] Platform Reporter: Philippe Detournay <theplouf>
Component: SWTAssignee: Niraj Modi <niraj.modi>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: lshanmug, markus.kell.r, niraj.modi, peter, theplouf
Version: 4.6Flags: lshanmug: review+
Target Milestone: 4.6.1   
Hardware: PC   
OS: Windows All   
See Also: https://git.eclipse.org/r/77672
https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d254df524a6ee0e2d474363527d42b9d5601b61a
Whiteboard:
Bug Depends on:    
Bug Blocks: 495269    
Attachments:
Description Flags
Reproduction
none
Updated TestSnippet none

Description Philippe Detournay CLA 2016-07-18 09:47:29 EDT 
GC created for Printer is wrongly applying autoScale.

Tested on Windows 10 with release version of SWT4.6 and autoScale set to quarter with Windows scaling set to 150%.

This has two consequences:
1) It is impossible to reliably draw "one inch" of anything unless you start doing arithmetics with both the device's DPI and the zoom factor (which requires to parse the system property), and
2) It is inconsistent with MacOSX implementation whereas the autoscale does not appear to apply for Printer GC.

The only workarounds I can think of so far are to try implementing scaling with rule-of-three based on the maximum device size (and try to get the real paper size by other means), or to perform Platform-based if-then-elses and to divide by zoom factor unless you run on MacOSX.

In any case, not a happy situation.
Comment 1 Lakshmi P Shanmugam CLA 2016-07-19 03:01:01 EDT 
Can you please attach a snippet to show the problem?

Sravan, please investigate.
Comment 2 Philippe Detournay CLA 2016-07-19 09:50:33 EDT 
Created attachment 263185 [details]
Reproduction

Reproduction of the problem on a Windows 10 with OS screen setting set to 150%, and having a default printer with paper size A4 (210mm x 297mm). Before getting the default display the paper size is correctly computed to 210x297, but once the default display is initialized then the paper size is 140x198.
Comment 3 Niraj Modi CLA 2016-07-20 06:49:04 EDT 
(In reply to Philippe Detournay from comment #2)
> Created attachment 263185 [details]

Thanks Philippe for the test snippet, I can reproduce the problem on Win7 as well.
Comment 4 Niraj Modi CLA 2016-07-21 07:22:05 EDT 
Created attachment 263236 [details]
Updated TestSnippet

Apart from Printer#getBounds() method, problem is also seen with Printer#getClientArea() method. Refer updated TestSnippet attached.

We don't need a AutoScale Up/Down for these two methods in Printer class, will share a gerrit patch shortly to fix this.
Comment 5 Eclipse Genie CLA 2016-07-21 07:38:39 EDT 
New Gerrit change created: https://git.eclipse.org/r/77672
Comment 7 Philippe Detournay CLA 2016-07-21 11:08:32 EDT 
Will the local change in the Printer class also affect the operations on GC's created on this Printer? I would imagine that graphical primitives sent to Printer GC's should also not be affected by the autoscaling.
Comment 8 Philippe Detournay CLA 2016-07-23 08:49:47 EDT 
FYI I tested on Ubuntu 16.04 64 (GTK): the bug is not there. So this appears to be Windows-only so far.
Comment 10 Niraj Modi CLA 2016-07-29 06:28:16 EDT 
Resolving this bug.
Comment 11 Niraj Modi CLA 2016-07-29 06:31:44 EDT 
(In reply to Philippe Detournay from comment #7)
> Will the local change in the Printer class also affect the operations on
> GC's created on this Printer? I would imagine that graphical primitives sent
> to Printer GC's should also not be affected by the autoscaling.

Please see bug 498876
Comment 12 Niraj Modi CLA 2016-08-02 05:42:42 EDT 
Verified fix in 4.7 M1 I-Build: I20160801-2000 on Win7.
Comment 13 Niraj Modi CLA 2016-08-05 09:14:50 EDT 
Verified fix in 4.6.1 M-Build: M20160803-1700 on Win7.