Bugzilla – Full Text Bug Listing
| Summary: | [api] ImageFileNameProvider/ImageDataProvider#getImageData(int) can't determine size of image | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Markus Keller <markus.kell.r> |
| Component: | SWT | Assignee: | Niraj Modi <niraj.modi> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | daniel_megert, eclipse, lshanmug, markus.kell.r, niraj.modi, sravankumarl |
| Version: | 4.5 | Flags: | daniel_megert:
pmc_approved+
|
| Target Milestone: | 4.5 M7 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://git.eclipse.org/r/44445 https://git.eclipse.org/r/44889 https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=72e691af6bca78442e18184dc1453e5eecb6f768 |
||
| Whiteboard: | |||
|
Description
Markus Keller
(In reply to Markus Keller from comment #0) > ... unless there's actually a monitor that uses > 100% resolution. Read: ... unless the shell is actually rendered on a monitor that uses 100% res. This currently doesn't work on the Mac, see bug 462555. And I missed to describe the unit of the "zoom" parameter: * @param zoom * The zoom level in % of the standard resolution (which is * 1 physical monitor pixel == 1 SWT logical pixel). * Typically 100, 150, or 200. Thanks Markus for your inputs, we will make the JavaDoc & code changes accordingly. Additionally, SWT will now cross-check on the size of the Image received, as per below contract: At 100% zoom - 16x16 pixels size image is mandatory, else SWT throws an exception At 150% zoom - either image can be null or it's 24x24 pixels size, else SWT throws an exception At 200% zoom - either image can be null or it's 32x32 pixels size, else SWT throws an exception Hope tweaking the API behavior & JavaDocs on these lines is allowed post M6. Will share a Gerrit on the same. (In reply to Niraj Modi from comment #2) > Additionally, SWT will now cross-check on the size of the Image received, as > per below contract: > At 100% zoom - 16x16 pixels size image is mandatory, else SWT throws an > exception No, you can't do that. The 16x16 convention is just something we use in the platform for button and item images. The SWT constructors must stay fully general and work for any size of images. What you could do when you load the 2nd+ zoom level is verify that the image size in the new zoom level matches the size at the previous zoom level (adjusted by the difference in zoom level). However, since that check would only happen when zoom levels are changed dynamically, and since you could run into rounding errors, I'd prefer not to have any such checks. > Hope tweaking the API behavior & JavaDocs on these lines is allowed post M6. Yes. And for clearly broken APIs, I wouldn't even expect to need PMC approval. (In reply to Markus Keller from comment #3) > > Hope tweaking the API behavior & JavaDocs on these lines is allowed post M6. +1. How to find out this zoom level when using owner-draw, e.g. in tables? (In reply to Thomas Singer from comment #5) > How to find out this zoom level when using owner-draw, e.g. in tables? We're not there yet. But I think this will become more clear after bug 399786 has been tackled. For Mars, we'll keep the good old "SWT coordinates" granularity in the GC APIs. But GC#drawImage(..) eventually needs to take the zoom level into account and choose the right image representation for you (maybe it already does -- didn't check). (In reply to Markus Keller from comment #6) > (In reply to Thomas Singer from comment #5) > > How to find out this zoom level when using owner-draw, e.g. in tables? > > We're not there yet. But I think this will become more clear after bug > 399786 has been tackled. For Mars, we'll keep the good old "SWT coordinates" > granularity in the GC APIs. But GC#drawImage(..) eventually needs to take > the zoom level into account and choose the right image representation for > you (maybe it already does -- didn't check). We have changed the drawImage function to take care of the zoomlevel. So it will use the right representation for the zoom level. We are not drawing images but graphics. How we can detect the zoom level for those? New Gerrit change created: https://git.eclipse.org/r/44445 New Gerrit change created: https://git.eclipse.org/r/44889 Gerrit change https://git.eclipse.org/r/44889 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=72e691af6bca78442e18184dc1453e5eecb6f768 Refactored [Win32/GTK]Image & DPIUtil classes to eliminate use of Maps via below git commits: - http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2f244e084ac5cca7ad4b8b06fd1e59e2a64926f4 - http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=518fac0461dd2835a14114db09ec2acb4011ad7b (In reply to Thomas Singer from comment #8) > We are not drawing images but graphics. How we can detect the zoom level for > those? By drawing graphics, I assume you are using something like Canvas to draw symbols etc.. Ok, as part of enhancement request bug 421383, we did created an internal(non-public) utility method DPIUtil#mapDPIToZoom which maps the DPI value received from public Device.getDPI() to equivalent zoom level. But this DPIUtil API is needed/valid for Windows and GTK code only, for Cocoa these DPI to zoom mapping doesn't hold true. Hope this helps, if someone wants to calculate the zoom in their client code for now. For having public API to detect zoom level, suggest you to raise a separate enhancement request, as we are in API freeze stage for Mars. Done with the required changes.. Resolving Verified the fix in build: I20150428-0100 Verified the fix in build: I20150428-0100 |