Bugzilla – Full Text Bug Listing
|
Description
Stephen Cooper
Created attachment 217737 [details]
Screenshot displaying the incorrect font size for the number "22"
This isn't as consistent as I thought it was. Currently the font size is much smaller (minuscule). This is after I changed my system preference display settings to "scaled -> more space" There are some more font problems: the console view is also too small, as is the variables view, when debugging. For the console view, it seems to depend on the displayed console: The console of a running/debugging process is too small, the stack trace console as well, the SVN conolse (Subclipse installed) is fine. Created attachment 220391 [details]
Screenshot showing console and variables view with very small fonts
Created attachment 220392 [details]
My font settings (as default)
When running Eclipse on an external display, the font size is fine, even when I move it to the Retina display. But when I start Eclipse without an external display, the fonts are too small (see screenshots), even when I move it to the (re-attached) external display. Wolfgang - thank you! You have pointed out to me why I sometimes have issues and sometimes not. It has to do with the external display. I have now discovered that if I set the external monitor as the primary monitor and then restart eclipse, fonts are the correct size. It wasn't sufficient for me to just have the external monitor connected - rather I had to have it set as the primary monitor. Created attachment 220482 [details]
Small fonts in Compare view
In Compare view, the fonts are also too small
As Stephen mentioned, this seems to happens only, if the Retina display is the primary display on Eclipse startup Created attachment 220659 [details]
Preferences dialog with big fonts
Just added an additional screen shot. I started this Eclipse on the Retina display without an external display connected. After attaching my external display (which then automatically becomes my primary display), I opened the preference dialog from the still running Eclipse. The fonts in the tree viewer are much too big (see screenshot).
So basically whether fonts are displayed correctly on a screen depends on whether Eclipse was started on the specific screen. Created attachment 222051 [details]
Fonts too large in editor and preferences menu
I also get much too large fonts sometimes on my Retina Macbook when working with an external screen (see attached screenshot). I can try to make the problem reproducible and describe the exact steps if it helps.
I am interested in fixing this bug. However, because of the many occurences that people have found it seems that it might be a big job. Is there anyone else who has a retina Macbook Pro and Java/Eclipse development experience that would be willing to help me? This bug has to be fixed before the retina UI switch detailed in bug 382972 can be enabled. I would set it as a dependency but I don't have the power to do that. We are working on getting a machine with retina display. Hopefully we will have it by the end of the year. I am going to work on this bug next week from Monday to Friday with my personal retina macbook. After that I will be back in an office with a linux computer. On my retina macbook (set to best for retina) with an external display that is not set as the main display I can not reproduce the problems with the console and variables view. The undisplayed tabs icon does show the number wrong but it displays too small instead of too large. Created attachment 222649 [details]
Probable cause of the number of hidden tabs displaying wrong.
I think I found the cause of the hidden tabs icon number displaying wrong.
I still have to find what is wrong with the equation and fix it though.
I have a feeling that searching the Eclipse codebase for more instances of display.getDPI() will find more problems.
Could an SWT commiter help me a bit here? I tried to fix the problem with the chevron but the problem is in the SWT custom CTabFolderRenderer class. When I cloned the org.eclipse.swt git repository with EGit and imported the project like I normally do when working on an Eclipse project it did not properly set up the build path for the "Eclipse SWT Custom Widgets" folder. Eclipse was showing that the package was "" and that java.Lang.Object could not be resolved. Obviously something is wrong with the way PDE is trying to build SWT. Could a commiter give me some help on how to properly debug and test custom SWT components? I suspect I will have to do a lot of work with SWT components to fix this bug. You need to copy the .classpath_cocoa file to .classpath. See the page below for more info http://www.eclipse.org/swt/git.php Created attachment 222656 [details]
Image of fixed CTabFolder chevron
Thanks! It builds properly and that page also showed me how to use the SWT examples which was helpful.
The code I highlighted in my previous attachment seems to have the purpose of making the font size smaller on higher resolution displays. This makes little sense since point sizes are based on inches and not pixels. I changed the code to use a fixed size of 10 points, which is the font size the formula would give if the monitor was the normal 72dpi.
I will clean up the code a bit then submit a patch. I'll try to reproduce the other problems noted in this bug tomorrow. Right now everything works fine for me but I suspect that is because of my external monitor, even though it is not my main monitor.
Created attachment 222657 [details]
Patch for small font in CTabFolder chevron
Here is my patch for the CTabFolder chevron that makes it use a constant font size of 10px. I moved the font size to a constant, added myself to the contributors log and commented a vague line of code that I figured out.
Created attachment 222658 [details]
mylyn/context/zip
(In reply to comment #17) > Created attachment 222649 [details] > Probable cause of the number of hidden tabs displaying wrong. > > I think I found the cause of the hidden tabs icon number displaying wrong. > > I still have to find what is wrong with the equation and fix it though. Cool, good catch! > I have a feeling that searching the Eclipse codebase for more instances of > display.getDPI() will find more problems. I very much hope so, would be nice to have Eclipse running correctly o Retina displays (In reply to comment #20) > I will clean up the code a bit then submit a patch. I'll try to reproduce > the other problems noted in this bug tomorrow. Right now everything works > fine for me but I suspect that is because of my external monitor, even > though it is not my main monitor. You can easily reproduce all the problems like this: Preparations: a) Without an external display, reconfigure your Retina display to have a higher resolution, for best effect use max resolution (1920x1200). b) Connect the external display. It should be configured to be your primary monitor when connected, so move the Dock to there. To reproduce the problems: 1. Start Eclipse (again without an external display), and run an Java application in the debugger. Open a few editors and the following views: Expressions, Variables, Console (possibly more have problems, Display.getDPI() might lead you to them). 2. Connect the external display, move Eclipse to there. The fonts in the views mentioned above should be too big. Also, set a breakpoint and use the value inspector (tooltip) while hovering over a variable. The font size is alos incorrect there. 3. Stop Eclipse and restart it, while the external display is still connected. Restar your debugging session. 4. Unconncect the external display. Now everything that was too big before is now way too small, so 10pt Fonts now look like 5pt or so. I tested all this with an external display connected via HDMI, but I would expect to make no difference with displays connected via MiniDisplayPort/Thunderbolt (and possibly an adaptor). Good hunting and many thanks for your effort! Thanks for the detailed instructions! I have managed to reproduce the large text once but not the small text. Also the subsequent time I tried to reproduce the large text it did not work. I will look through the code and try and find the source of the problem. I have a feeling it is a problem with the tree view since it happens in the preferences pane as well. I'm actually going to change my guess of the problem location to some kind of Font Cache. The reasoning behind this is the problem has appeared in many places for many people, I can't always reproduce the problem and I can't reproduce the problem for all views that people have screenshots of it happening to. When reproducing the problem, it's important whether you start Eclipse with external display connected or not and whether you start it on the main screen (i.e. the Retina display with bigger resolution or the external screen respectively). Ok, I can now reproduce it consistently in the PDE debugger. I have found out that the correct FontData object (11pt) is being passed into the tree view so the problem must be in the rendering code. I hope I can find it without too much debugging since reproducing the problem is super annoying. Ok I have found the root problem: When a Font object is created after the external display is plugged in, with an Eclipse that was started on a Retina display, the font displays twice as large as it usually does. If you then call getFontData on that font, it displays the correct height of 11. However, if you create the font on a retina display and then plug in an external monitor, it displays correctly. The thing is, if you call getFontData on that Font object the font data it returns says it is 5.5pt tall, half the height it is supposed to be, yet it displays correctly at an apparent 11pt. I imagine this bug is the cause of all the other view's font problems. Fixing this issue should close the bug. I have already submitted a patch for the Info.plist file. If I can fix this bug then Eclipse should be fully retina-ready. Created attachment 222739 [details]
Code that causes the main problem with Font
I think I found the code that causes this problem, the hard part is figuring out the purpose of this code and then fixing the problem without breaking everything.
Unlike the DPI check for the chevron I have a feeling this code is very important and I will have to re-engineer rather than remove it.
Created attachment 222740 [details]
Labeled screenshot of the debugger showing the problem.
Could an SWT commiter help answer this question?
There is code in the Cocoa version of the Font resource that scales the font size by the ratio of the device DBP to the main screen DPI. This ends up doubling or halving the font sizes in certain situations involving Retina displays with external monitors.
I assume this code was added to fix some bug or solve some problem. Removing the scaling would solve this bug but I don't want to reintroduce another bug. I personally can not think of a reason for this code to exist. There is no record in the contributor log of any bugs fixed for this file.
If someone knows what the purpose of this code is I could fix it without reintroducing the other bug.
(If you can't view the screenshot the problem is on line 305 of Font.java in the cocoa version of SWT)
Ok I figured out how to dig through the git commit history and found the source of that code, it was a fix for Bug 219133. I'm going to investigate how I can fix this bug and still keep that bug resolved. Silenio Quarti can you shed some light on this issue? The fix for the printer bug didn't cause the problem, the original fix used getDPI() which for screens is the same as the other call to get screen resolution. When Bug 241062 was fixed it caused dpi to be the actual retina display resolution, causing the size scaling to mess up. Some reference was made to useless code so it is possible that the scaling can be simply removed. I need to know for sure before I remove it though. Great debugging work, Tristan! If you could send me a patched SWT jar, I would try this on my machine. What causes the problem: 1. When the Device object for the screen is created on startup the .dpi property is set to the main screen DPI. 2. The new monitor is now plugged in and becomes the main screen. 3. The font is scaled by the ratio of the .dpi property over the new main screen dpi. 4. If the new main screen is lower resolution then the font size is multiplied by 144/72 = 2. Making the fonts twice as large as they should be. 5. If the new main screen is the retina screen then the font size is multiplied by 72/144 = 1/2. Making the fonts half as large. As far as I can tell the Font scaling code is useless but Silenio Quarti may be able to refute that. I will remove the code in my local repository and test it out. I will try and figure out how to make a patched SWT JAR, at the moment I am not aware of how to do so. (In reply to comment #34) > What causes the problem: > 1. When the Device object for the screen is created on startup the .dpi > property is set to the main screen DPI. > 2. The new monitor is now plugged in and becomes the main screen. > 3. The font is scaled by the ratio of the .dpi property over the new main > screen dpi. > 4. If the new main screen is lower resolution then the font size is > multiplied by 144/72 = 2. Making the fonts twice as large as they should be. > 5. If the new main screen is the retina screen then the font size is > multiplied by 72/144 = 1/2. Making the fonts half as large. > > As far as I can tell the Font scaling code is useless but Silenio Quarti may > be able to refute that. > > I will remove the code in my local repository and test it out. I will try > and figure out how to make a patched SWT JAR, at the moment I am not aware > of how to do so. I believe the height scaling is still necessary for printers. It was supposed to be a noop on the screen because the DPI was always 72/72. This is not the case now with the retina display. I am wondering if the DPI returned Display.getDPI() should was be the logical DPI (72/72) even for retina displays. Is the rectangle returned by Diplay.getBounds() logical or physical? How about the rectangles returned for the monitors (Display.getMonitors())? Created attachment 222844 [details]
Patched SWT plugin archive.
Here is a patched SWT plugin archive.
I'm not sure if I exported it successfully. I did an export on the org.eclipse.swt.cocoa.macosx.x86_64 project that contains the files I modified. I got a minor error but it seems to have worked anyway.
If this doesn't work I have a plain ANT build of the jar. Although I think if you unzip this it has the same jar inside it.
One possible solution:
Point getScreenDPI () {
NSScreen screen = getPrimaryScreen();
NSDictionary dictionary = screen.deviceDescription();
NSValue value = new NSValue(dictionary.objectForKey(new id(OS.NSDeviceResolution())).id);
NSSize size = value.sizeValue();
double /*float*/ scaling = 1;
if (OS.VERSION >= 0x1070) {
scaling = screen.backingScaleFactor();
}
return new Point((int)(size.width / scaling), (int)(size.height / scaling));
}
Thanks! That looks like a better solution that won't break anything else and is more resistant to future breakage. I will implement and test that code and reintroduce the font scaling.
The Display.getBounds() function is in logical pixels since the result Rectangle {0, -316, 3360, 1216} is the size of the rectangle in logical pixels of both my monitors put together. The width of 3360 is 1440 (logical retina width) + 1920 (my other display)
Created attachment 222846 [details]
New patched SWT plugin archive.
Your code worked with no problems. Retina displays now show a 72x72 DPI.
I have attached a new plugin archive for Wolfgang to test.
Tristan, can you upload a patch file? Sorry for the delay uploading a patch. I have been on a linux computer for the last while and have to remember to do it when I'm using my mac. If you want to create a patch file yourself all I did was replace the Display.getScreenDPI() method with the one in Silenio's comment. I will try to remember to submit a patch next time I use my mac. Sorry that it took me so long but I just now found some time for testing... I swapped the MacOSX Cocoa SWT plugin provided by Tristan with my existing plugin (I kept the original file name, so as to trick Equinox into accepting this file and not to have to fight with p2) and everything looks fine now. I tested it forwards and backwards, i.e. starting Eclipse on the external screen, detaching and running on the Retina display and vice versa. I also tested with the original plugin version from Juno SR1 and the one supplied by Tristan, so I saw the problem with the original plugin, it was gone with Tristan's patch and it reappeared when reverted. The change seems to do the trick, I will keep the patched version until SR2 or Kepler M4 (one of which will hopefully include the patch) is released and report if I find any more font problems. Thanks to everybody for the effort to get this fixed! Thanks for testing the patch. It has been committed to master (4.3 branch) http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=5148ba36d3ddf0aa6ecd7c6a53403a3b5cb005ee Leaving open to include in 4.2.2/3.8.2. Fixed in 4.2.2/3.8.2: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_8_maintenance&id=5e8905d741f00b44c8daeba6316e9407d9e100b9 http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_2_maintenance&id=e8a4ff64f73999309aaee295a952a7b40b119e25 Please could someone try the next maintenance (on Wednesday, November 14) and reopen if not fixed? Great! Do note that without committing my patch for bug 382972 this does not do anything. So even though this is in the next release it won't do anything for everyone who does not know how to manually enable retina support. Do you know any committers that could commit my patch to rt.equinox.binaries? (In reply to comment #45) > Great! > > Do note that without committing my patch for bug 382972 this does not do > anything. So even though this is in the next release it won't do anything > for everyone who does not know how to manually enable retina support. > > Do you know any committers that could commit my patch to rt.equinox.binaries? I can commit the patch for bug#382972 :-). 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? Verified with M20130116-1800 *** Bug 384082 has been marked as a duplicate of this bug. *** |