Open GoogleCodeExporter opened 9 years ago
The solution you gave seems to be the way to go about it.
Best case scenario is to have the fractional metrics enabled across the board
and this gets us far closer to that. Even though it's obviously going against
the very nature of cross platform Java code, working is working.
Only gotcha there I think is that it would disable it for all mac platforms.
Are we sure that there are no mac machines for which fractional metrics doesn't
introduce an ellipsis?
Original comment by allain.lalonde
on 8 Sep 2010 at 7:07
Original comment by heue...@gmail.com
on 22 Dec 2010 at 2:06
Per
http://developer.apple.com/library/mac/documentation/Java/Reference/Java_Propert
iesRef/Articles/JavaSystemProperties.html
There are some system properties on OSX that might affect how text is rendered
and how this rendering hint is applied:
apple.awt.graphics.EnableQ2DX
Determines whether hardware acceleration is used to speed up rendering of simple primitives like images, lines, rects, and simple characters. In addition to using this flag, you need to enable Quartz 2D acceleration in the Quartz Debug application, included with the Xcode Developer Tools for Mac OS X.
This is strictly a developer option. Java applications intended for use on Mac OS X should not rely on the presence of Quartz 2D acceleration.
The default value is false.
apple.awt.graphics.UseQuartz
Determines whether Apple’s Quartz renderer is used instead of Sun’s 2D renderer.
The default value is true for J2SE 5.0 and false for Java SE 6.
Thus the OS check might not be sufficient.
See also Issue 117 which documents my frustration with Piccolo2D text rendering
in general.
Original comment by heue...@gmail.com
on 2 Mar 2011 at 4:34
Consider also OpenJDK builds on Mac OSX
http://code.google.com/p/openjdk-osx-build/
Original comment by heue...@gmail.com
on 2 Mar 2011 at 6:00
Here's a summary of this issue to date:
While the default for all platforms seems to be FRACTIONAL_METRICS_ON
("fm_on"), Piccolo2D explicitly sets FRACTIONAL_METRICS_OFF ("fm_off") for
painting of PSwing nodes. As I understand it, this decision has been a part of
the PSwing class for a long while now and the primary motivation for doing this
is to avoid rendering of ellipses on Mac OS X platforms (by using "fm_off", we
prevent Mac OS from rendering ellipses for some text renderings that, due to
fractional metrics calculations can't fully render within their bounds.)
After running several tests, however, it seems that painting w/ "fm_off" causes
more unpleasant behavior across systems than using the default of "fm_on". On
all systems, using "fm_off" causes noticeable jittering while zooming. On
Ubuntu/Java4, ellipses are actually rendered in this mode and not in "fm_on".
And on Windows 7, using Java4, ellipses are rendered regardless of the setting.
I tested on a subset of {Win7, Snow Leopard, Ubuntu10} x {Java4, Java6} x
{FRACTIONAL_METRICS_ON, FRACTIONALMETRICS_OFF} and the outcome images will come
soon attached with tell-tale filenames:
| "fm_off" | "fm_on"
Windows7
Java4: jittering; ellipsed no jitter; ellipsed
Java6: jittering slight jittering
Ubuntu10
Java4: jittering; ellipsed slight jittering
Java6 (openjdk): jittering; slight artifacts no jitter; noticeable artifacts
Mac/Snow
Java6: jittering slight jittering; ellipsed
It appears impossible to avoid ellipse-rendering using RenderingHints. Also,
using the default rendering hint "fm_on" yields much better behavior (little or
no jittering) otherwise.
It seems clients can avoid ellipses by explicitly setting preferred sizes on
their components, so there is a workaround.
With this data, I believe the *correct* route is to use the default "fm_on"
rendering hints (which is default on all systems I tested on), which also
resolves this issue.
I don't believe we can do this, however, in 1.3.* releases as clients may
already rely on this behavior. 1.3.* clients can workaround this issue by
overriding paint() behavior (not ideal, I know.)
Looking for P2D developers to comment. My vote is to move this ticket to 2.0
with the plan of removing our use "fm_off" in 2.0.
Original comment by atdi...@gmail.com
on 27 Mar 2011 at 9:23
Attaching Windows 7 outcomes -- {Java4, Java6} x {"fm_on", "fm_off"}
Original comment by atdi...@gmail.com
on 27 Mar 2011 at 9:24
Attachments:
[deleted comment]
Attaching Ubuntu outcomes -- {Java4, Java6 (openjdk)} x {"fm_on", "fm_off"}
Original comment by atdi...@gmail.com
on 27 Mar 2011 at 9:26
Attachments:
Attaching Mac OS X (Snow L.) -- {Java6} x {"fm_on", "fm_off"}
Original comment by atdi...@gmail.com
on 27 Mar 2011 at 9:27
Attachments:
Speaking for PhET...
+1 for the proposal to move this ticket to 2.0. Also OK to default to "fm_on",
as long as we have some way to globally change to "fm_off" in client code.
Also of note is that we have recently experienced the Mac OS ellipsis problem
with Arabic characters at font size > 14, with both "fm_on" and "fm_off"
scenarios.
Original comment by cmal...@pixelzoom.com
on 29 Mar 2011 at 12:12
Are you able to workaround ellipses by explicitly setting preferred bounds on
the component (giving it larger width)?
Original comment by atdi...@gmail.com
on 29 Mar 2011 at 3:18
Original comment by atdi...@gmail.com
on 29 Mar 2011 at 3:18
Yes, I am able to work around ellipses in a component by explicitly increasing
its preferred width.
Original comment by cmal...@pixelzoom.com
on 30 Mar 2011 at 7:17
Original comment by heue...@gmail.com
on 26 Nov 2013 at 9:11
Original issue reported on code.google.com by
reids%co...@gtempaccount.com
on 8 Sep 2010 at 2:51