Community
Participate
Working Groups
Build Identifier: 20110916-0149 In order to display nicely on a "Retina" MacBook Pro, there are certain steps which need to be taken by developers. See https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Introduction/Introduction.html#//apple_ref/doc/uid/TP40012302 It would be nice if Eclipse were updated. Right now, the fonts all look very poor in Eclipse because all pixels are doubled. Reproducible: Always Steps to Reproduce: 1. Purchase a MacBook Pro with Retina Display 2. Start Eclipse 3. Wince. :)
Please could you attach a screen shot and tell me whether the Info Window for Eclipse has the "Open in Low Resolution" option checked. https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html#//apple_ref/doc/uid/TP40012302-CH4-SW1
Created attachment 217658 [details] screenshot of eclipse's info window on retina macbook pro the Open in Low Resolution checkbox is checked and is disabled (grayed-out)
According to "High Resolution Guidelines for OS X", the fact that it's checked and dimmed means Eclipse isn't a cocoa app. This doesn't make sense. Here's the quote from https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html#//apple_ref/doc/uid/TP40012302-CH4-SW1 "Apps that aren’t Cocoa apps have this checkbox selected and unavailable (dimmed). " I will say that as a workaround, the user can go into Displays setting and instead of the default "Best for Retina Displays" choose the "Scaled - more space" option. While it does introduce eye-strain, it does make Eclipse look better. People with seriously good vision can download an app from http://wineskin.doh123.com/tiki-view_blog_post.php?postId=51 and set the resolution to 2880 x 1800. Then Eclipse looks just as sharp as any other app. Unfortunately my vision isn't that good anymore.
Here's the workaround: Do "Show package contents" on the Eclipse.app. Edit Contents/Info.plist. Just above </dict> </plist> Place this: <key>NSHighResolutionCapable</key> <true/> Then, log out or make a copy of the app so that OSX will notice the change. Now, the info window will not show "Open in Low Resolution" as checked. Launch Eclipse and enjoy your new retina awesomeness.
that did, indeed, fix it for me. however, i had to make make a copy of eclipse for it to take effect. i am not sure where osx caches the plist but logging out and even restarting did not help. in fact, if i rename my new folder to the old one after deleting the original and restarting the info window still reverts back to open in low res.
Apparently, OSX caches the info.plist rather aggressively. Here's what worked for me: copy Eclipse.app and paste it into the same folder (you end up with Eclipse copy.app) Delete Eclipse.app Rename Eclipse copy to Eclipse. Apparently, you can also just move the .app file to a different folder (like your desktop) and back again to clear the cache.
Yup - that fixed it for me too (copy, delete original & rename copy). Looks much nicer. Thanks!
Of course, all icons still need to be updated to higher resolution. But they're not quite as much of an eyesore as the font was.
Hi, thanks for this workaround! Has anyone gotte the Android Virtual Devices to work with this? The mouse-clicks are not mapped to the right positions within the AVD. Look at his screenshot: http://www.abload.de/img/screenshot2012-06-22au3k0s.png Thanks in advance ;)
Just downloaded Juno RC3, and it works nicely out of the box.
That's strange as nothing has changed on our side. I would expect it to still be low res. Did you unzip into a new directory?
Nope - I take that back. I had switched my screen resolution away from "best for retina display" to "more space" (I *wish* they would specify pixel dimensions!) Doing that essentially levels the playing field between high-res applications and normal applications. When I switched back to "best for retina" then the Juno RC3 still has the same font issues. :( And get info has the "Open in Low Resolution" checkbox checked and dimmed. The same fix for Indigo fixes it for Juno too.
Thanks for the workaround. Works like a charm on the 4.2 release! It would be nice to have permanent fix in for SR1 though.
Just CC'ing myself to track this one. It's definitely one to patch ASAP: we are looking at moving all our developers to Retina MacBooks.
This workaround causes kernel panics for me. When I have run in low resolution unchecked I get a kernel panic at least once every hour or two. Running with run in low resolution checked, I have not gotten a kernel panic. I have nothing else running.
It would also be great to have 2x icons that render well at retina native resolution.
(In reply to comment #16) > It would also be great to have 2x icons that render well at retina native > resolution. Yes, I totally agree. I think we can say that these very high DPI displays are here to stay and that other manufacturers will also start to use them. So preparing for this would be a good idea. Creating new icons for all of Eclipse is a huge job and will probably take a lot of effort. But supporting 2x icons should not be too hard.
the low resolution checkbox workaround worked for me as well. Eclipse is now usable, although there are some problems left: some views display too small fonts. See bug 383305 for that issue.
Just as a side note: You can also run "touch Eclipse.app" from a console to update the plist file.
I may have found the Info.plist file used to build the Eclipse packages but when I look at it it says the version is 3.7 which seems wrong. I'm not on a mac right now so I can't actually check if my Juno distribution says it is 3.7. The file I am looking at is org.eclipse.equinox.executable/bin/cocoa/macosx/x86_64/Eclipse.app/Contents/Info.plist in the rt.equinox.binaries repository.
Could a commiter or someone with the right priviledges please set bug 383305 as a dependency of this bug? I don't think the Info.plist switch should be enabled until the font issues are resolved.
Lucky break: if you change the Info.plist to enable retina support and then run a copy of eclipse with PDE for development, the debug copy of Eclipse will also be retina enabled.
Created attachment 222697 [details] Patch against rt.equinox.binaries to enable Retina display support Here is a patch to add the necessary key to the info.plist file. While I was changing the Info.plist files I bumped the version to 4.2. Right now if you have a mac app for Juno it says the version is 3.7.
Silenio Quarti and I fixed the bug with fonts that blocked this. My patch to the Info.plist can now be committed to fix this bug. The problem is the patch is against rt.equinox.binaries and this bug is in SWT so the relevant committers will not be notified. Does anyone know an equinox committer that could commit this?
(In reply to comment #24) > Silenio Quarti and I fixed the bug with fonts that blocked this. > > My patch to the Info.plist can now be committed to fix this bug. > > The problem is the patch is against rt.equinox.binaries and this bug is in > SWT so the relevant committers will not be notified. Does anyone know an > equinox committer that could commit this? I can commit the patch this :-). But first, there are still a number of open bugs that only happen on retina displays (just search for retina). Do any of those bugs are bad enough that we should fix before adding NSHighResolutionCapable to the Info.plist?
I think the following bugs should maybe be fixed/investigated before enabling retina mode: - Bug 383717 - I will check if I can reproduce this. I'm not sure this is retina related. - Bug 391870 - This one is interesting. I don't notice it in the IDE but it might be a problem. - Bug 388814 - This is only a problem if it occurs only with the retina plist switch on. I have posted a comment asking. The retina switch only impacts the IDE so it shouldn't affect bugs for other SWT apps. Many of the retina bugs are problems that involve blurriness which occur whether retina is enabled or not. Enabling retina does not affect these bugs. Once these bugs are resolved or deemed unimportant then I think we can enable retina mode.
Bug 383717 isn't related to retina and has already been fixed.
Ok good. It also turns out that Bug 388814 occurs without the retina plist key so that leaves only the painting bug. I haven't noticed any problems in the IDE related to that bug and it may occur even without the retina plist key. I think that it is now safe to commit the patch to the Info.plist in rt.equinox.binaries.
I discovered a flaw that happens during refactoring in JDT perspective, reported as #394044 might be a dependency to this bug.
I agree that it is a bug that should be fixed the thing is without the plist patch it is blurry all the time. Enabling the plist patch will enable that bug but it is better to be blurry some of the time than all. It should probably be set as a dependency but it should not stop the plist patch from being committed.
Sure, so how to handle all the high-dpi issues that will arise? I got another one: If you show line numbers in editors, they are blurry, too.
I recommend adding new bugs with retina in the bug name. I think this bug pertains specifically to enabling the retina plist switch. If the effect of the other bug is worse with the switch turned on then it is relevant to this bug. Other things that are blurry even with the switch on should not be part of this bug since without the switch everything is blurry. Does this sound like a good plan? Have you created a bug/is there a bug for the line numbers being blurry? If not, you should definitely create one. Contributors with retina MacBooks can search for "retina" to find them. I'm definitely interested in getting Eclipse to work with retina MacBooks but since the one week when I was working at home I have mostly been working on a linux computer so I probably won't be much help fixing further bugs.
*** Bug 391592 has been marked as a duplicate of this bug. ***
I have enabled the flag in master (4.3) and 4.2.x/3.8.x branches. http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=da42537d650995726232e1ff6b1428ea8330a6d9 http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R3_8_maintenance&id=9640ee0a38b3a51a9fad653680f27da720c695a6
Excellent! Thanks!
Awesome, thanks for the workaround - Elipse looks much better on my MacBook Pro's retina display! I couldn't stand the blurred text after first installing.
Since the icons continue to be shown as blurred, I have been trying to change the icons (with default size of 16x16) in Workbench toolbar to 32x32 customized icons. But the toolbar scaled up the icon provided by me and its showing it as a bigger icon. Since the same icon show nicely using a photo viewer, I think the size-increase is happening from eclipse side. If so, how can I stop this scaling up of icons? Or When can we expect suitable icons for Mac retina display? Thanks
(In reply to comment #37) > Since the icons continue to be shown as blurred, I have been trying to > change the icons (with default size of 16x16) in Workbench toolbar to 32x32 > customized icons. > > But the toolbar scaled up the icon provided by me and its showing it as a > bigger icon. Did you try to simply add the scaled icons with a name of myicon@2x.gif as specified in the OS X Human Interface Guidelines [1]? This might just do the trick, if Eclipse simply passes the filename of the icon to the OS for displaying. [1] section "Provide the Correct Resources and Let OS X Do the Work" in http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/IconsImages/IconsImages.html
Also see here [1] for the document "Testing and Troubleshooting High-Resolution Content" provided by apple. It details, e.g. how to set a standard display to show high resolution content and gives some hints for the @2x icons. [1] http://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Testing/Testing.html#//apple_ref/doc/uid/TP40012302-CH6-SW1
(In reply to comment #39) > Also see here [1] for the document "Testing and Troubleshooting > High-Resolution Content" provided by apple. It details, e.g. how to set a > standard display to show high resolution content and gives some hints for > the @2x icons. > > [1] > http://developer.apple.com/library/mac/#documentation/GraphicsAnimation/ > Conceptual/HighResolutionOSX/Testing/Testing.html#//apple_ref/doc/uid/ > TP40012302-CH6-SW1 Thanks for your response. Well I tried with the following images: myIcon@2x.png (a 32x32 image) But there was no difference, it continued to be shown as a large image with 32x32 dimensions instead of 16x16 dimensions with high resolution. Seems like the NSImage object performs the necessary scaling as mentioned in the following link: http://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Optimizing/Optimizing.html I am not sure if eclispe internally uses NSImage for image display.
I also think that there is a need for enhancing Image object to allow high-density representations. In my case, I am drawing some thumbnails in code and the result is blurry when shown on screen. I would like to be able to draw a x2 representation to make the thumbnail clear on high-density screen.
I tried hacking around Cocoa API and came up with the following approach to add high-density representation: Image im = createThumbnailImage(width, height); Image img2x = createThumbnailImage(width * 2, height * 2); Object rep = ReflectionUtils.callPrivateMethod(img2x, "getRepresentation"); Object handle = ReflectionUtils.getPrivateFieldValue(img, "handle"); Class repClass = ReflectionUtils.classForName("org.eclipse.swt.internal.cocoa.NSImageRep"); ReflectionUtils.callPrivateMethod(handle, "addRepresentation", new Class[] { repClass }, new Object[] { rep }); img2x.dispose(); This seems to work. Can anyone with more knowledge of Cocoa API confirm that this is safe thing to do and there are no resource leaks? For this code to be generic enough x2 factor should be probably replaced by NSScreen#backingScaleFactor(). Maybe the SWT API for this case could be as simple as Image#addRepresentation(Image anotherImage).
Bug 403993 should cover the image scaling request.
This is not only on MacBook Pro, but it is the same problem on more and more machines. I have a lot of DPI problems with Eclipse on my laptop: 2880x1620 at 15.4" display. I give +1 for this to be resolved sooner.
*** Bug 403993 has been marked as a duplicate of this bug. ***
The SWT API to support High resolution images has been provided as part of bug 421383. Now the these API needs to implemented on the UI/Jface to support the high resolution icons
(In reply to Sravan Kumar Lakkimsetti from comment #46) > The SWT API to support High resolution images has been provided as part of > bug 421383. > > Now the these API needs to implemented on the UI/Jface to support the high > resolution icons Great that we have this, but feels a little bit short term for platform.ui to react on this. Do we have someone from our platform UI team looking at this?
I have it on my list to investigate. I hope to have some time this week. If anybody else wants to take it though, please do.
(In reply to Brian de Alwis from comment #48) > I have it on my list to investigate. I hope to have some time this week. > If anybody else wants to take it though, please do. Thanks Brian. Markus will look at this since he also reviews the SWT implementation. But any other feedback is of course also welcome!
Moving to RC1, Markus please correct target if you do not plan to address that in RC1.
I don't think it's realistic to schedule this for Mars. Bug 399786 comment 8 describes the fundamental problems with the current SWT APIs (short version: SWT APIs should shield clients from platform differences, but here, they just pass them on 1:1). Bug 459412 comment 8 contains fragments that add @1.5x and @2x versions of those icons that have already been converted to SVG. Attachment 252811 [details] shows how it looks like on Windows. On the Mac, it's not as bad, but the mix of low- and high-resolution icons also looks strange. And even if all icons were converted, we still have issues with images that are drawn in code: - view menu drop-down button - icons with overlays (e.g. Problems view, and all Java element icons) - line number ruler
(In reply to Markus Keller from comment #51) > - view menu drop-down button Created Bug 466511 to replace it with an icon
(In reply to Markus Keller from comment #51) > I don't think it's realistic to schedule this for Mars. > > Bug 399786 comment 8 describes the fundamental problems with the current SWT > APIs (short version: SWT APIs should shield clients from platform > differences, but here, they just pass them on 1:1). I do not think there is a problem with SWT api. The main difference you are pointing here is automatic zooming of images (like Cocoa) in windows and Linux. We have already raised a bug 462952 for this purpose, and we are will handle it in the next release as an enhancement.
IntelliJ IDEA today's blog post: http://blog.jetbrains.com/idea/2015/07/intellij-idea-15-eap-comes-with-true-hidpi-support-for-windows-and-linux/
For me in Linux Mint the interface doubles automatically with the rest of the system, but the icons are micro. For now I 'fix' this by literally doubling the images in all resources using this bash script: https://stackoverflow.com/questions/20718093#29032397 Doesn't seem to work for all the icons, but it makes Eclipse a lot more workable on UHD/HiDPI.
Created attachment 256730 [details] screenshot of eclipse form controls on Retina (Mars) The problem with blurry text still persists in some Forms controls in Eclipse Mars. This screenshot is from the help slideout panel in the "New Java Project" wizard. Note how the text in the top of the panel is sharp, but the links below are blurry. I think this is a FormText control. Also I note that if I mouseover any of those blurry links, they become sharp and remain sharp until disposed.
Created attachment 256748 [details] Line numbers in Java editor on Eclipse Mars Line numbers still blurred in Java editor on Eclipse Mars
Created attachment 256774 [details] Screenshot of Neon M2 on Windows 10, High DPI Laptop Testing Neon M2 on a brand new Dell XPS 13 (2015 version), Windows 10 Pro, 3200x1800 resolution, Display Settings with "Change the size of text" at the default recommended value of 250%. The overall visual quality is abysmal... Look at: - The size of the icons in all the toolbars - The size of the text in the left side and folder pane of the dialog box - The size of the text in the Welcome pane Eclipse is basically unusable. For the record, Mars behaves the same. OTHER SCALING ISSUES I NOTICED: - The splash screen is minuscule
(In reply to Dmitry Gusev from comment #57) > Created attachment 256748 [details] > Line numbers in Java editor on Eclipse Mars > > Line numbers still blurred in Java editor on Eclipse Mars See comment 17 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=399786#c17) and 18 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=399786#c18) in bug 399786
I see the problem unresolved for almost 5 years now. I do not think screen producers will be lowering screen resolutions any time soon. Do you have plan to fix this?
(In reply to Janek Smith from comment #60) > I see the problem unresolved for almost 5 years now. I do not think screen > producers will be lowering screen resolutions any time soon. > > Do you have plan to fix this? Janek, could you please try the latest SmartGit 7.1 preview: http://www.syntevo.com/smartgit/preview If that works, Eclipse also could support it with the current API. The most important problem seems that OS X handles hi-dpi screen support different (IMHO easier to implement) than Windows (don't know about different Linux window managers yet).
I can confirm that smartgit works nicely for me in QHD.
For OS X supporting the HiDPI-resolutions seems very simple: just create the images used for toolbars or which are drawn on the user interface with the ImageDataProvider constructor, load the actual images not as Image but as ImageData and return them in the ImageDataProvider. Unfortunately, some methods like deriving disabled images from ImageDataProvider-images does not yet work. Setting, e.g., a toolbar button such an image will automatically draw the HiDPI variant if required. The same when using GC.draw(image, x, y). Otherwise one actually does not need to care. For Windows it is different: we load "normal" images, either the 100% or 200% zoom variants, depending on the DPI information (SmartGit does not support other scaling factors yet). The problematic thing is that every pixel-related size has to be scaled (e.g. distances between controls, preferred sizes of controls, default table column widths, ...), but only if it is not based on calculated values from other sizes. Because of lack of an public API we currently use the Display's dpi / 96. Unfortunately, this does not work well when a) changing the display's dpi when the application is running, b) if different monitors have different dpi values. My conclusion: Apple has made it much simpler for application developers to implement HiDPI-support.
I forgot: there are some consequences out of the different behaviors on OS X and Windows directly painting: painting a 1-pixel line on Windows produces a very thin line, on OS X this results actually in a 2-pixel line. The HiDPI mode on OS X is very good hidden for the application - it just gets the smaller screen resolution reported, the display's dpi values remain the same.
FYI (AFAIK) Markus Keller is working on this support for 4.6.
(In reply to Thomas Singer from comment #64) > I forgot: there are some consequences out of the different behaviors on OS X > and Windows directly painting: painting a 1-pixel line on Windows produces a > very thin line, on OS X this results actually in a 2-pixel line. The HiDPI > mode on OS X is very good hidden for the application - it just gets the > smaller screen resolution reported, the display's dpi values remain the same. Hi, This exactly what we are fixing as a part of bug 399786. The current api will scale up any drawing call after the fix and there will be new set of apis if you want to a draw according to the absolute pixels. Please refer 479614 also. Thanks
It looks like bug 399786 especially is a problem for double-buffering (self-drawn images), for loaded ImageDataProvider-Images it already works fine (on OS X). What I currently don't understand is the situation on Linux: on Ubuntu 14.04 (?) there is a scaling slider in the screen section that seems to scale all fonts, but the display's dpi value remains for me at 96, so we can't detect the scaling level.
I second what @Dario Luparello mentioned. Confirmed this in the following configuration: - Eclipse platform 4.5.1 64bit - Asus ZenBook Ux303 - (recommended) DPI Scaling %250 - Windows 10 Home 64bit - QHD+ display with 3200x1800 resolution (recommended) This makes Eclipse completely unusable. Icons look tiny but font in editor looks fine. I am seriously considering other IDEs or lowering (drastically) my resolution.
*** Bug 483773 has been marked as a duplicate of this bug. ***
duplicate bug is solved but the issue is not(windows - 4.5.1 + neon m4). is there any place that tracks now this problem?
(In reply to Janek Smith from comment #70) > duplicate bug is solved but the issue is not(windows - 4.5.1 + neon m4). > is there any place that tracks now this problem? We are working on this issue and should be available for M5.
*** Bug 485591 has been marked as a duplicate of this bug. ***
holy crap !! this bug was submitted 3.5 years ago and still not fixed? This makes Eclipse totally unusable in any higher resolution, small screen laptop. Should I return my brand new shiny laptop? naww... may be I should try IntelliJ then.
(In reply to Karthik Karuppannan from comment #73) > holy crap !! this bug was submitted 3.5 years ago and still not fixed? This > makes Eclipse totally unusable in any higher resolution, small screen > laptop. Should I return my brand new shiny laptop? naww... may be I should > try IntelliJ then. As you should know, Eclipse is an open source project and as such often moves a bit slowly in areas where no-one is funding development or where there is no pressure. In this case the pressure is quite low. Despite of what you think; Eclipse works just fine on high DPI displays. I've been using it on my retina-Mac(s) for years with only minor issues. Some of which this report adresses. So feel free to make Eclipse better by helping out on fixing them. A well formulated bug report is also of high value if you're not inclined to do any programming.
(In reply to Torkild Resheim from comment #74) > As you should know, Eclipse is an open source project and as such often > moves a bit slowly in areas where no-one is funding development or where > there is no pressure. In this case the pressure is quite low. FYI - Markus is planning this feature for Eclipse 4.5 M5 or M6. AFAIK we still waiting for SWT features, see dependent bugs.
Created attachment 259218 [details] Neon M4 windows10 yoga 3 pro
Mass move to M6
when can we expect eclipse Retina ready?
will M6 stay on schedule?
*** Bug 487549 has been marked as a duplicate of this bug. ***
*** Bug 485994 has been marked as a duplicate of this bug. ***
Quite a few bigger changes to SWT went into M6 (mostly to shield SWT API clients from HiDPI differences on GTK and Win32). Adoption work (e.g. support for HiDPI icons) will take place in M7.
*** Bug 492205 has been marked as a duplicate of this bug. ***
Mass move to 4.6 RC1. We might push out more to 4.7.
(In reply to Markus Keller from comment #82) > Quite a few bigger changes to SWT went into M6 (mostly to shield SWT API > clients from HiDPI differences on GTK and Win32). Adoption work (e.g. > support for HiDPI icons) will take place in M7. What does "adoption" mean in this context? Does it mean that the various plugins have to provide PNGs in different resolutions (as described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=459412#c8) or is there still "fundamental" work to be done in the platform to enable plugins to contribute icons in multiple resolutions? With the Neon M6 the auto-scaling of SWT does mess up the icons on windows (with 150% Zoom level). See https://bugs.eclipse.org/bugs/show_bug.cgi?id=489831 for details. Do you have a plan "B" if you cannot complete the adoption work (this bug was moved to RC1)? Will you then switch off the SWT auto-scaling?
Hi Markus, Just a quick check in context of (https://bugs.eclipse.org/bugs/show_bug.cgi?id=490213#c3) Are you planning to fix this bug for Neon/RC1 ?
What do other projects have to do to support HDPI properly? Is there some documentation somewhere? In the migration guide perhaps? I.e. do we have to provide icons of different sizes and adjust other code? Thanks!
(In reply to Marc-Andre Laperle from comment #87) > What do other projects have to do to support HDPI properly? Is there some > documentation somewhere? In the migration guide perhaps? I.e. do we have to > provide icons of different sizes and adjust other code? Thanks! +1 We have resolved a couple of HiDPI issues by trial and error ourselves (e.g. with platform-specific code for handling images), but in the mean-time the API has been improved. I'm not sure we are using the API as designed. It would be very useful to have a guide which shows every aspect of the HiDPI-aware programming with SWT. It's time for a new issue?
New Gerrit change created: https://git.eclipse.org/r/73063
(In reply to Eclipse Genie from comment #89) > New Gerrit change created: https://git.eclipse.org/r/73063 This enables support for image_name@2x.png images for clients of org.eclipse.jface.resource.ImageDescriptor#createFromURL(URL). Gerrits with the actual @2x icons will follow for each repo. For Neon, SWT will only support integer scale factors out of the box, see bug 493462. Unfortunately, we still have a few projects in the Eclipse SDK for which no SVG icons are available, so those will still use the 16x16 GIFs at this time: org.eclipse.jface.text org.eclipse.search org.eclipse.ui.editors
Sorry, but I'm not a good person to test this, as I do not have a high resolution display (and about to leave work for today). Adding Brian as reviewer in the hop that he is still around due to the the different time zone.
Created attachment 261834 [details] hidpi-fragments@2x.zip Here's an update site zip with the @2x HiDPI fragments. It has been created from a version of eclipse.platform.images that included https://git.eclipse.org/r/#/c/71351/ .
Gerrit change https://git.eclipse.org/r/73063 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a34cc649d3ab603db89a2e843e90ec6aa510671f
Verified and submitted. I verified that substituting different @2x icons were shown. Nice to see crispy @2x icons!
New Gerrit change created: https://git.eclipse.org/r/73080
New Gerrit change created: https://git.eclipse.org/r/73081
New Gerrit change created: https://git.eclipse.org/r/73082
New Gerrit change created: https://git.eclipse.org/r/73083
New Gerrit change created: https://git.eclipse.org/r/73085
New Gerrit change created: https://git.eclipse.org/r/73086
New Gerrit change created: https://git.eclipse.org/r/73087
Created Gerrits to push the icons into their respective bundles. Here are the irregularities I encountered while verifying the commits: Reopened bug 465780, which broke org.eclipse.pde.ua.ui. Filed bug 493931 for wrong GIFs in org.eclipse.ui.console. Filed bug 493936 for wrong icon locations in JFace: org.eclipse.jface.action.images org.eclipse.jface.fieldassist.images org.eclipse.jface.wizard.images In eclipse.platform.ui, there were a few bundles that didn't contain any d* folders for disabled icons. I've removed the @2x versions there as well.
Gerrit change https://git.eclipse.org/r/73081 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=ade485e1b5e0fb0614194de5cc62ce59caf3e350
Gerrit change https://git.eclipse.org/r/73085 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=171068a26d7a979c58987e661e95a759548e1bfc
Gerrit change https://git.eclipse.org/r/73080 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=84b4c15fa5ba0191f863c7943e59939da83b52c1
Gerrit change https://git.eclipse.org/r/73082 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=828930f051915d3f4fa77c173742d2b758173653
Gerrit change https://git.eclipse.org/r/73083 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=aae65f35d05a011d97898367bb23b77be479b6b8
Gerrit change https://git.eclipse.org/r/73086 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=8fb8cc2c0fc9f641a46c0854d512ff7f1917d7de
Gerrit change https://git.eclipse.org/r/73087 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=54e7bdf533614d851bfda037adf355eb39ffad68
The basic infrastructure is done, and I've verified it in I20160518-2000. New problems should go into new bugs.
Shouldn't we also store the "@2x" PNGs also in http://git.eclipse.org/c/platform/eclipse.platform.images.git as we do for the "normal" PNGs?
(In reply to Matthias Becker from comment #111) > Shouldn't we also store the "@2x" PNGs also in > http://git.eclipse.org/c/platform/eclipse.platform.images.git as we do for > the "normal" PNGs? Yes, but I didn't have time to complete the tooling. Will be done after bug 493929 is fixed. Working with Apache Batik is a painful experience, since we - had hard time understanding bug 493994 - still don't know why Tony's generated icons are not identical to the ones I get when running the same Maven command on the same SVG files
Created attachment 262219 [details] Eclipse Neon M7 and newest RC
Today I tested the newest stuff from http://download.eclipse.org/eclipse/updates/4.6milestones And compared it with an Eclipse Neon Version that already did the scaling but did not have the @2x-PNGs. In this version the icons are scaled up and very blurry. With the version that includes the @2x-PNGs the icons are sharp but they are smaller (looks like the state before the up-scaling was activated). You can see this in the "Eclipse Neon M7 and newest RC" attachment. What's wrong here? Do do I misunderstand something.
(In reply to Matthias Becker from comment #114) > Today I tested the newest stuff from > http://download.eclipse.org/eclipse/updates/4.6milestones > Try latest I-build from http://download.eclipse.org/eclipse/downloads/
https://www.eclipse.org/eclipse/news/4.6/platform.php#swt-autoscale is the main N&N entry about HiDPI support, and it contains links to other entries. https://www.eclipse.org/eclipse/news/4.6/platform.php#swt-autoscale-tweaks explains that auto-scaling of SWT coordinates and images now only happens in steps of 100% by default. See bug 493462 for more information about this change in RC1. Attachment 262219 [details] "Eclipse Neon M7 and newest RC" looks like the system is set to a 150% scaling factor, which uses 100% icons in the Neon release. You can set the vm argument "-Dswt.autoScale=quarter" to get the 4.6M6 behavior back, but the icons won't look good. Unfortunately, we currently don't have a way to properly interpolate icons with transparency on Windows. See bug 495417 for planned improvements in Oxygen (4.7).
(In reply to Lars Vogel from comment #115) > (In reply to Matthias Becker from comment #114) > > Today I tested the newest stuff from > > http://download.eclipse.org/eclipse/updates/4.6milestones > > > > Try latest I-build from http://download.eclipse.org/eclipse/downloads/ It's the same.
(In reply to Markus Keller from comment #116) > Attachment 262219 [details] "Eclipse Neon M7 and newest RC" looks like the > system is set to a 150% scaling factor, which uses 100% icons in the Neon > release. Yes. The scaling is set to 150%
Why is this bug marked as fixed? I downloaded RC3 and there still are a lot of icons in Eclipse which look blurry. The Run Button looks nice and sharp, but the Search button is still blurry also the Open Web Browser Button and many more!
The Splash Image when you start Eclipse also looks blurry.(Tested on MacBook Retina 13)
(In reply to john elhm from comment #119) Please open a new bug report with a screenshot and provide details about the platform and screen resolution that you use.
Created here -> https://bugs.eclipse.org/bugs/show_bug.cgi?id=495716
Created attachment 262579 [details] Form control still blurry in Neon 4.6.0 RC3 Why is this bug marked as fixed? The Form controls are still blurry in Neon RC3. See attachment.
so how much long are we supposed to wait for the fix ?
See Bug 468945 for some follow up work, e.g. org.eclipse.e4.ui.workbench.swt had the 2x variants but was missing the normal png file.
Hi, I am having issues inside my eclipse application in context with icons. The icons appear small on high resolution monitor . I thought converting .png files to .svg files will solve the issue . But it's not solved . I tried it in Eclipse 3.8 . Does Eclipse 3.8 and Eclipse 4.6 supports for SVG icons?
The HiDPI support is only in 4.6 (Neon) and above; it isn't in 3.8. You need to create pixel-doubled versions of your images and place them alongside your normal images with a `@2x` prefixed to the extension. So if you have a 16x16 image in `icons/ov_hdr.png` then you should create a 32x32 image in `icons/ov_hdr@2x.png`. There is no support for SVG images, though you can use them as the source for a SVG -> PNG conversion. The Eclipse Platform uses such a rendering pipeline for generating the Eclipse images, which you can see at: http://git.eclipse.org/c/platform/eclipse.platform.images.git/
*** Bug 489831 has been marked as a duplicate of this bug. ***
This bug still exists. I'm on Windows 10, with a high dpi display. The bug appears when using both Oxygen and Photon. I've uploaded a screenshot.
Created attachment 271231 [details] Eclipse Photon small icons
(In reply to Solomon Ritzow from comment #131) > Created attachment 271231 [details] > Eclipse Photon small icons They look normal size/scale to me?
(In reply to Solomon Ritzow from comment #130) > This bug still exists. I'm on Windows 10, with a high dpi display. The bug > appears when using both Oxygen and Photon. I've uploaded a screenshot. The scaling works at integer multiples like 100%,200% etc. Looks like you are using 150%. for this you need to tweak scaling using -Dswt.autoScale parameter as described in https://www.eclipse.org/eclipse/news/4.6/platform.php#swt-autoscale-tweaks
