Bugzilla – Full Text Bug Listing
| Summary: | [Win32][HiDPI] Issues with Display.getPrimaryMonitor().getBounds() | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | David Gabor <gabor.david> |
| Component: | SWT | Assignee: | Niraj Modi <niraj.modi> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | arunkumar.thondapu, ericwill, gabor.david, lshanmug, markus.kell.r, niraj.modi, peter, sravankumarl |
| Version: | 4.6 | Flags: | sravankumarl:
review+
lshanmug: review+ markus.kell.r: review+ |
| Target Milestone: | 4.6 RC4 | ||
| Hardware: | PC | ||
| OS: | Windows All | ||
| See Also: |
https://git.eclipse.org/r/74182 https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=97abb3ddbca0c44d326e5ceda32c2c37dc41d2aa |
||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 479614 | ||
Present in 4.6RC2 and 4.6RC3 In Display#getPrimaryMonitor() api we are adjusting the dimensions to points. but the monitor dimensions are already in points we should not do scaledown. I did not looked at the impact of this change yet. But should be fixed in 4.6.1 I believe Hi David, Just a quick check, what's the impact of this bug ? Does it affecting any of Eclipse epp packages ? (In reply to Niraj Modi from comment #3) > Hi David, > Just a quick check, what's the impact of this bug ? > Does it affecting any of Eclipse epp packages ? I don't know whether it has any impart on the Eclipse epp packages. In our application the initial dimensions of some pop-up windows are calculated using the dimensions of Display.getDefault().getPrimaryMonitor().getClientArea(). Investigated this issue further, can see this issue with Snippet120 which uses Display.getPrimaryMonitor().getBounds() method call. Root-Cause: After fix for bug 489528 monitor bounds/clientArea remain in Points: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=c53936dceeaaebf51a17a15fd42cf358c3c2feca With above patch AutoScaleDown of Monitor bounds/clientArea in Display.getPrimaryMonitor() method is not more needed(which as initially done considering the monitor bounds/clientArea to be in pixels) Reverting this unnecessary AutoScaleDown operation fixes the problem. New Gerrit change created: https://git.eclipse.org/r/74182 TestCase for this Bug is Snippet120: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet120.java +1 for RC4.
Tested at 100%, 125%, and 200% on Windows 7 using attachment 262161 [details]. Also verified the various Monitor#getClientArea().
Gerrit change https://git.eclipse.org/r/74182 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=97abb3ddbca0c44d326e5ceda32c2c37dc41d2aa (In reply to Markus Keller from comment #8) > +1 for RC4. > > Tested at 100%, 125%, and 200% on Windows 7 using attachment 262161 [details] > [details]. Also verified the various Monitor#getClientArea(). Thanks Markus/Lakshmi/Sravan for you quick reviews, resolving now. Verified fix in I20160601-2000 on Win7 using attachment 262161 [details] and Snippet120.java
|
Configuration: Windows 10 Two 4k (3840x2160) monitors, configured to be horizontally next to eachother. Main monitor (on the right side) has zoom level set to 200% Other monitor (on the left had side) has zoom level set to 250% The following values are returned by SWT: Display.getDefault().getBounds(): Rectangle {-1920, 0, 3840, 1080} Display.getDefault().getPrimaryMonitor().getBounds(): Rectangle {0, 0, 960, 540} Display.getDefault().getPrimaryMonitor().getClientArea(): Rectangle {0, 0, 960, 520} The latter two seem to be very low, I believe it should be twice these values. I am not sure what is required for the first one, width and height might be correct in that case.