Community
Participate
Working Groups
slakkimsetti/HighDPIChangesforNeon branch On GTK and Win32, the traditional constructors of Image create a high-resolution pixel buffer. But on Cocoa, those constructors currently create a low-resolution pixel buffer. This is causing the blurry line number ruler (bug 399786 comment 0), view menu button, and CTabFolder overflow chevron/number. SWT/Cocoa needs to switch to a scheme where the internal image representation is also the high-DPI variant iff a high-DPI monitor is available. That "iff" is crucial. We must avoid performance hits for non-retina systems, see also bug 462555. And for retina systems, we also need to avoid the overhead of updating multiple image representations all the time. We haven not addressed the problem of dynamic resolution changes on GTK/Win32 yet. I'm on Windows 7, which AFAIK doesn't support that yet. But on Ubuntu 14.04 and Mac OS X, resolutions can change at run time. We need a good strategy to deal with this in the same way on all platforms. The hard question is what to do with Image objects that have been created in the old resolution.
(In reply to Markus Keller from comment #0) > slakkimsetti/HighDPIChangesforNeon branch > > On GTK and Win32, the traditional constructors of Image create a > high-resolution pixel buffer. But on Cocoa, those constructors currently > create a low-resolution pixel buffer. > > This is causing the blurry line number ruler (bug 399786 comment 0), view > menu button, and CTabFolder overflow chevron/number. > > SWT/Cocoa needs to switch to a scheme where the internal image > representation is also the high-DPI variant iff a high-DPI monitor is > available. Hi Markus, I'm not sure if this is required for all the images created with the old constructors. I think it's expected to see blurry images when low resolution images are used. The client has to use high resolution image to fix the problem. Only for images that are drawn using GC we need to fix the blurry images. This may require creating a high resolution representation in Image class and making sure that the GC draws on the correct representation. I tried this with the CTabfolder example and was still seeing the same problem. I'm still investigating this. One thing I noticed, the line numbers become sharp when I zoom-in the editor using Cmd++. Do you know why this happens?
Will look at it in RC1
(In reply to Lakshmi Shanmugam from comment #2) > Will look at it in RC1 I've a patch that fixes the line numbers and chevron problem. There are few issues with the patch such as icons on the ruler are not scaled, the block selection position is not correct. I'll attach the gerrit patch with the WIP shortly. I plan/hope to finish this for RC1.
New Gerrit change created: https://git.eclipse.org/r/72184
I've attached the WIP patch that fixes most of the GC.draw* methods. Launching eclipse with the patch looks good except for some problems where GC.drawImage is used. The patch fixes the line number & ctabfolder chevron blurriness problem. Changes to drawImage are required and are not straightforward. Also, making the changes to drawImage at this point is risky as we would not have enough time to test & fix any regressions. Hence, moving to 4.6.1.
Any progress on this one? The blurry line numbers are very apparent to the use.
(In reply to Matthias Becker from comment #6) > Any progress on this one? The blurry line numbers are very apparent to the > use. As mentioned by Lakshmi in comment 5, the problem with GC.drawImage still remains to be sorted out before the bug can be fixed in its entirety. I will continue the work on this one and will target for a fix in 4.7 M3 which can then be backported to 4.6.2.
*** Bug 501178 has been marked as a duplicate of this bug. ***
Haven't been able to work on this for 4.6.2, moving to 4.6.3.
Moving to 4.7 and assigning back to Lakshmi as she's investigating this once again...
The problem with the approach in the patch is that it doesn't work in a multi-monitor setup. With the patch, while drawing on an Image using GC, drawing happens only on the hi-res representation of the Image. To support multi-monitor setup, we have to draw on both the representations. This approach will work only for Cocoa & not for Windows & GTK. We need find a common solution to draw on hi-res Images using GC based on the APIs available on those platforms. The solution could be to provide event/callback so that drawing on the Image can happen inside the client code. This has to be investigated further, will re-target to 4.8. I'll create a separate bug to fix the blurry line numbers in client code.
(In reply to Lakshmi Shanmugam from comment #11) > I'll create a separate bug to fix the blurry line numbers in client code. Opened Bug 516293
There are three scenarios where clients create a GC and then draw on it: (A) Directly draw onto a Control, usually in response to a paint event. Examples: StyledText, org.eclipse.jface.fieldassist.ControlDecoration#paintListener In this scenario, paint listeners will get another paint event when the shell is moved to a monitor with a different zoom level. => No problem. (B) Use GC#copyArea(Image, int, int) to take a screenshot or store the current contents of a Drawable into another Image. => Not sure how to handle this. Probably needs a new API to clarify which zoom level will be copied. (C) Draw into an Image and eventually ... (C1) ... draw the modified Image using a GC in any of the three ways. (C2) ... use Image#getImageData(int) to get hold of the results of the drawing operations. => A strategy could be to "record" all drawing operations that were performed in a GC. When someone requests the result at a different zoom level, "re-play" the drawing operations. I see quite a few problems with the record/playback approach: 1) Existing code could create a GC and not dispose it for a long time. The drawing log could become very long, and SWT wouldn't know when to dump it. 2) Clients that use drawImage(Image, ...) don't expect the Image to be accessed again after the call returned. Such Images may very well be disposed or altered at the time SWT tries to re-play a recorded script. 3) Clients could create multiple GCs for the same Drawable. It would be quite a challenge to synchronize interleaved drawing operations from multiple GCs. I think for (C), we need a new API that will look similar to the existing image provider APIs. E.g.: public interface GcImageProvider { public void drawImage (GC gc); } This would basically implement the record/re-play facility by forcing clients to draw everything in one batch. Note that the proposed API does not pass a zoom level, since that should be fully transparent to clients. I.e. coordinates, line widths, patterns, and fonts should get scaled for free, and GC#drawImage(..) should automatically pick the right zoom level. The GC(Drawable, ...) constructors could then be deprecated, and new constructors GC(Control, ...) and GC(Device, ...) could be provided for scenario (A). (In reply to Lakshmi Shanmugam from comment #1) > One thing I noticed, the line numbers become sharp when I zoom-in the editor > using Cmd++. Do you know why this happens? It doesn't happen;-) With bigger letters, it's only less visible that they are blurry.
Isn't this issue with the blurry line numbers fixed in the meantime. At least on macOS the line number are crisp.
(In reply to Matthias Becker from comment #14) > Isn't this issue with the blurry line numbers fixed in the meantime. > At least on macOS the line number are crisp. The fix has been made in the client code. This bug is to investigate a fix in SWT.
The problem with LineNumberRuler has been fixed. Need to investigate if SWT can provide an API to draw high resolution images using GC. Moving to 4.9.
Retargetting.
Lakshmi, any progress on this. This blocks bug 535068 that tracks the scaling issues of the chevron on macOS.
(In reply to Matthias Becker from comment #18) > Lakshmi, any progress on this. This blocks bug 535068 that tracks the > scaling issues of the chevron on macOS. Sravan is working on this problem currently, I believe he will be updating the bug with more details.
New Gerrit change created: https://git.eclipse.org/r/130912
There are multiple problems to be solved 1. The existing code needs to be generalized to use scale factor. currently it uses 2 as fixed scale 2. while selecting the representation in gc drawing, if there is already an image representation in the image object which is not equivalent to current scaling factor, then the current code draws on top of blank image rather than the existing image. 3. Mac co-ordinate system is little different. In other OS the coordinates (0,0) at top left, but in case of Mac it bottom left. This needs to be adjusted while we are dealing with scaling of location. 4. There are issues with location of drawn images. Solving the issue with co-ordinate system might fix this issue. 5. There is a problem of double scaling in CTabFolder. Needs to be addressed 6. Need to address transformation of images like rotate, flip etc.
New Gerrit change created: https://git.eclipse.org/r/132283
Fixed double scaling issue in snippet139
Assigning to Sravan, as he is working on it.
There are still some issues we trying to resolve. We will fix them in 4.11. Moving out of 4.10
New Gerrit change created: https://git.eclipse.org/r/136476
Created attachment 277502 [details] Snippet I did some analysis on this and I am stuck here at this problem In eclipse we create GraphicsContext using drawable’s internal_new_GC. On Mac there are two types of GC one created with NSWindow and another with ImageRep. In the attached Snippet For drawing on Canvas we were using GC we got from the callback. And on the other we use GC created from the imageRep. When we run this snippet one can see the image drawn on can vas is quite sharp and the other one is blurry. There are couple of problems for the second image to appear blurry 1. The imageRep used is of 100% image rep instead of 200% image rep on hidpi screen. This can be solved by applying https://git.eclipse.org/r/136476 2. The drawing calls are using device coordinates(pixels) instead of user coordinates(pints). In case of canvas the same calls are using user coordinates. The problem I am having is how to create a NSGraphicsContest from image rep that user user coordinates(points) Any help is appreciated.
(In reply to Sravan Kumar Lakkimsetti from comment #27) > Created attachment 277502 [details] > Snippet > > I did some analysis on this and I am stuck here at this problem > > In eclipse we create GraphicsContext using drawable’s internal_new_GC. On > Mac there are two types of GC one created with NSWindow and another with > ImageRep. > > In the attached Snippet For drawing on Canvas we were using GC we got from > the callback. And on the other we use GC created from the imageRep. > > When we run this snippet one can see the image drawn on can vas is quite > sharp and the other one is blurry. There are couple of problems for the > second image to appear blurry > > 1. The imageRep used is of 100% image rep instead of 200% image rep on hidpi > screen. This can be solved by applying https://git.eclipse.org/r/136476 > 2. The drawing calls are using device coordinates(pixels) instead of user > coordinates(pints). In case of canvas the same calls are using user > coordinates. > > The problem I am having is how to create a NSGraphicsContest from image rep > that user user coordinates(points) > > Any help is appreciated. Found solution to second problem as well. Used NSAffineTransform to set the appropriate scaling while drawing on the imageRep. Now most of the scaling works. Found one place where there is double scaling. The icon in dialog boxes have double scaling. Need to fix this before pushing this change
Fixed double scaling issue also. Patch is ready for review
Fixed getImageData method on non-retina display as well.
Ran all snippets in Retina and non retina mode. Did not find any problems. If any one has an idea what more that needs to be tested, please provide me snippet I will test them.
Here are the details of code changes 1. A new method createImageRep has been added to create a new imageRep with the target size. 2. getRepresentation() is modified to return appropriate reps based on scalefactor. Now it will not return 100% rep on 200% screen. 3. Added a new tranform (scaling) to NSGraphicsContext so that GC draws according to the scalefactor. 4. Caret with Image is still using Core graphics, there we need to use 100% image. While creating new ImageRep we could select InterpolationNone or InterpolationHigh. InterpolationHigh breaks platform UI. Raised bug 544569 to address this. Because of this I set the interpolation none. I am attaching the eclipse screen shots with Interpolation high and None in the next comments. Testing done(in retina and non-retina mode): 1. All snippets 2. Control examples 3. Tests. If any one has any other test case that I need to try please attach it here.
Created attachment 277617 [details] Eclipse Screenshot with interpolation High cause red border around icons
Created attachment 277618 [details] Eclipse Screenshot with interpolation None. Results in blurry images
(In reply to Sravan Kumar Lakkimsetti from comment #33) > Created attachment 277617 [details] > Eclipse Screenshot with interpolation High cause red border around icons Where is that red border? I don't see any.
Created attachment 277619 [details] pink borders with interpolation high and low I can still see pink borders in child Eclipse with the latest patch. In the attached screenshot, left side image is with InterpolationHigh and right side image is with InterpolationNone. Changing the interpolation doesn't fix the pink borders, it just makes them thinner. IMO, it's better to keep interpolation high as it gives smooth scaling and non-blurry images and fix Bug 544569 instead.
(In reply to Matthias Becker from comment #35) > (In reply to Sravan Kumar Lakkimsetti from comment #33) > > Created attachment 277617 [details] > > Eclipse Screenshot with interpolation High cause red border around icons > > Where is that red border? I don't see any. Me neither. Does one need a high-res monitor to see them in that image?
(In reply to Lakshmi Shanmugam from comment #36) > Created attachment 277619 [details] > pink borders with interpolation high and low > > I can still see pink borders in child Eclipse with the latest patch. > In the attached screenshot, left side image is with InterpolationHigh and > right side image is with InterpolationNone. Changing the interpolation > doesn't fix the pink borders, it just makes them thinner. > > IMO, it's better to keep interpolation high as it gives smooth scaling and > non-blurry images and fix Bug 544569 instead. Is bug 544569 a regression compared to 4.10? If so, how likely is it that SWT can provide a fix for 4.11? Is the provided Gerrit change considered to be the fix for this bug here? I do not see any API in it as requested by this bug report.
(In reply to Dani Megert from comment #38) > (In reply to Lakshmi Shanmugam from comment #36) > > Created attachment 277619 [details] > > pink borders with interpolation high and low > > > > I can still see pink borders in child Eclipse with the latest patch. > > In the attached screenshot, left side image is with InterpolationHigh and > > right side image is with InterpolationNone. Changing the interpolation > > doesn't fix the pink borders, it just makes them thinner. > > > > IMO, it's better to keep interpolation high as it gives smooth scaling and > > non-blurry images and fix Bug 544569 instead. > Is bug 544569 a regression compared to 4.10? If so, how likely is it that > SWT can provide a fix for 4.11? > You can consider it as a regression. But in the hdpi scenario the clients should not deal with pixels unless they are implementing image providers. This particular case client is is actually marking each pixel as transparent. In hidpi with automatic scaling of images there will be a hue change at the icon borders causing this logic to fail. You can see this problem only at curves. To mitigate this problem I suggested using Image interpolation to none. The bug 544569 is in Platform UI. SWT will not be able provide a fix there. > > Is the provided Gerrit change considered to be the fix for this bug here? I > do not see any API in it as requested by this bug report. There is no API required. I managed to get the functionality without any api. Marcus raised this bug thinking that this might require some new API. We already implemented Linux and Windows without any new API. I tried the same approach I am using in Linux and the same has been adopted here.
(In reply to Sravan Kumar Lakkimsetti from comment #39) > The bug 544569 is in Platform UI. SWT will not be able provide a fix there. Well, not "SWT", but why can't you provide a fix? > > Is the provided Gerrit change considered to be the fix for this bug here? I > > do not see any API in it as requested by this bug report. > > There is no API required. OK, then please update this bug and the Gerrit change summary accordingly.
(In reply to Dani Megert from comment #40) > (In reply to Sravan Kumar Lakkimsetti from comment #39) > > The bug 544569 is in Platform UI. SWT will not be able provide a fix there. > Well, not "SWT", but why can't you provide a fix? > I know what is causing the problem but I don't know how fix it yet. Its certainly not possible for 4.11. > > > > Is the provided Gerrit change considered to be the fix for this bug here? I > > > do not see any API in it as requested by this bug report. > > > > There is no API required. > OK, then please update this bug and the Gerrit change summary accordingly. Updated the summary of this bug and
The pink border issue is worse than some blurred images and we have no idea how the change might affect other products. This change is too risky at this point. Sravan, please either find another solution or work with Kalyan to fix the Platform UI bug. This should be done early 4.12.
Any progress on this issue?
(In reply to Matthias Becker from comment #43) > Any progress on this issue? The attached Gerrit works, but it causes bug 544569. I am working on that bug now
*** Bug 544341 has been marked as a duplicate of this bug. ***
*** Bug 546946 has been marked as a duplicate of this bug. ***
Created attachment 278563 [details] Screenshot without fix for bug 544569
Created attachment 278564 [details] Screenshot with fix for bug 544569
Since bug 544569 is resolved. Requesting Lakshmi to complete the review. The interpolation has been changed to high to produce smooth images.
The changes (patch-set 15) look good! Verified with SWT snippets and Eclipse, the images are drawn in high resolution and look good. In Eclipse, the text drawn using GC for example in the Manifest Editor and Eclipse Help are also sharp. One problem I noticed, the text in the rotated images is blurry in Snippet 139. But, the text in the original image is drawn sharp.
(In reply to Lakshmi Shanmugam from comment #50) > The changes (patch-set 15) look good! > Verified with SWT snippets and Eclipse, the images are drawn in high > resolution and look good. In Eclipse, the text drawn using GC for example in > the Manifest Editor and Eclipse Help are also sharp. > One problem I noticed, the text in the rotated images is blurry in Snippet > 139. But, the text in the original image is drawn sharp. the rotate image method in snippet139 uses 100% representation for rotate and flip. It doesn't use methods available from SWT. So it is expected to have blurry image when the image is rotated or flipped. Fixing Snippet139 is out of scope of this bug.
I am raising PMC approval request as the earlier request has been denied. I just want to have proper approvals on the bug
(In reply to Sravan Kumar Lakkimsetti from comment #52) > I am raising PMC approval request as the earlier request has been denied. I > just want to have proper approvals on the bug Are all discussed issues (e.g. red/pink artefacts) resolved?
(In reply to Dani Megert from comment #53) > (In reply to Sravan Kumar Lakkimsetti from comment #52) > > I am raising PMC approval request as the earlier request has been denied. I > > just want to have proper approvals on the bug > Are all discussed issues (e.g. red/pink artefacts) resolved? Pink border issue is resolved. previous: https://bugs.eclipse.org/bugs/attachment.cgi?id=278563 current: https://bugs.eclipse.org/bugs/attachment.cgi?id=278564 From my side I don't have any more pending issues
Merged to master through https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=8b8534bd4e8b9d7e275fe3026fa6ea8f5cdc4e16
(In reply to Sravan Kumar Lakkimsetti from comment #51) > (In reply to Lakshmi Shanmugam from comment #50) > > The changes (patch-set 15) look good! > > Verified with SWT snippets and Eclipse, the images are drawn in high > > resolution and look good. In Eclipse, the text drawn using GC for example in > > the Manifest Editor and Eclipse Help are also sharp. > > One problem I noticed, the text in the rotated images is blurry in Snippet > > 139. But, the text in the original image is drawn sharp. > > the rotate image method in snippet139 uses 100% representation for rotate > and flip. It doesn't use methods available from SWT. So it is expected to > have blurry image when the image is rotated or flipped. > > Fixing Snippet139 is out of scope of this bug. @Sravan, please add the Bug number for this problem here for reference.
Gerrit change https://git.eclipse.org/r/136476 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=8b8534bd4e8b9d7e275fe3026fa6ea8f5cdc4e16
Verified in I20190520-18050
New Gerrit change created: https://git.eclipse.org/r/143002
Gerrit change https://git.eclipse.org/r/143002 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=19eb5e74bea73b5281e32b5abe8954f3662b5b0f
(In reply to Eclipse Genie from comment #60) > Gerrit change https://git.eclipse.org/r/143002 was merged to [master]. > Commit: > http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=19eb5e74bea73b5281e32b5abe8954f3662b5b0f > @Sravan The images in the N&N entry are very big. The width should not be > 520 pixels. Please update them.
New Gerrit change created: https://git.eclipse.org/r/143059
Gerrit change https://git.eclipse.org/r/143059 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=ac9771c0018d516ede438adb8f722adf639aee11
