Bugzilla – Full Text Bug Listing
| Summary: | [HiDPI][Win32][GTK] Unify behavior of Display#getDPI() | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Markus Keller <markus.kell.r> |
| Component: | SWT | Assignee: | Sravan Kumar Lakkimsetti <sravankumarl> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | karl, lshanmug, niraj.modi, peter |
| Version: | 4.6 | ||
| Target Milestone: | 4.8 M3 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://git.eclipse.org/r/106439 https://git.eclipse.org/r/110298 https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=8a0bd0377d6fca6a35b11ddc5a724b5205e269b8 |
||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 517055 | ||
|
Description
Markus Keller
It also wouldn't hurt to fix the code locations: Device#getDPI() should be an abstract method, and the Display and Printer classes should contain the implementations. Currently, the implementation for Display is in Device. We will look into this in 4.8. This will require shuffling of apis New Gerrit change created: https://git.eclipse.org/r/106439 (In reply to Eclipse Genie from comment #3) > New Gerrit change created: https://git.eclipse.org/r/106439 Hi Sravan, I'm not sure that the refactoring is really useful if Device.getDPI() is not changed into abstract method. Markus suggested in comment#1, to make it an abstract method, but that change will be binary incompatible (according to https://wiki.eclipse.org/Evolving_Java-based_APIs_2). Also, with the patch Device.getDPI() now returns (0,0), this is API breakage as behavior of an existing API changes. Sravan, the main problem to be fixed here is:
> Unify the behavior of Display#getDPI() on GTK and Win3 at fractional scaling
> factors. See analysis in bug 495134 comment 8.
>
Let's try to address this.
(In reply to Lakshmi Shanmugam from comment #4) > (In reply to Eclipse Genie from comment #3) > > New Gerrit change created: https://git.eclipse.org/r/106439 > > Hi Sravan, > I'm not sure that the refactoring is really useful if Device.getDPI() is not > changed into abstract method. Markus suggested in comment#1, to make it an > abstract method, but that change will be binary incompatible (according to > https://wiki.eclipse.org/Evolving_Java-based_APIs_2). > Also, with the patch Device.getDPI() now returns (0,0), this is API breakage > as behavior of an existing API changes. This is exactly the problem I am having. Can you please suggest how to proceed? (In reply to Sravan Kumar Lakkimsetti from comment #6) > (In reply to Lakshmi Shanmugam from comment #4) > > (In reply to Eclipse Genie from comment #3) > > > New Gerrit change created: https://git.eclipse.org/r/106439 > > > > Hi Sravan, > > I'm not sure that the refactoring is really useful if Device.getDPI() is not > > changed into abstract method. Markus suggested in comment#1, to make it an > > abstract method, but that change will be binary incompatible (according to > > https://wiki.eclipse.org/Evolving_Java-based_APIs_2). > > Also, with the patch Device.getDPI() now returns (0,0), this is API breakage > > as behavior of an existing API changes. > > This is exactly the problem I am having. Can you please suggest how to > proceed? We can skip this cleanup due to the reasons in comment#4. Please see comment#6 for the problem to fixed and comment#0 for other cleanups. New Gerrit change created: https://git.eclipse.org/r/110298 Making getDPI() in Device as abstract is causing binary incompatibility. So dropped the idea of making it abstract. Update the javadoc with the information about logical dpi. Gerrit change https://git.eclipse.org/r/110298 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=8a0bd0377d6fca6a35b11ddc5a724b5205e269b8 (In reply to Markus Keller from comment #0) > Follow-up to bug 495134. > > Unify the behavior of Display#getDPI() on GTK and Win3 at fractional scaling > factors. See analysis in bug 495134 comment 8. This was already done. GetDPI always returns logical dpi > > Additional required cleanup: > > - Display#getDPI() API must tell that this is not the real screen resolution > but a some kind of "logical DPI". Changes have been done > > - org.eclipse.swt.custom.CTabFolderRenderer#drawChevron(GC, Rectangle, int) > must stop using this API. This is required. We use logical dpi to calculate height required. This logical dpi changes from each of the platform so we use getDPI api to calculate the height required. > > - Consider removing all native code that effectively just returns a constant > that is independent of the environment. This is already done Verified in Eclipse SDK Version: Photon (4.8) Build id: I20171023-2000 OS: Linux, v.4.4.0-97-generic, x86_64 / gtk 3.18.9, WebKit 2.18.0 |