Hi Sergey,
src/macosx/classes/sun/java2d/opengl/CGLLayer.java
48 private int scale = 1;
src/macosx/classes/sun/awt/CGraphicsDevice.java
222 public int getScaleFactor() {
src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java
45 protected final int scale;
(there's also other usages of int in shared code)
Why do we use integer values here? There's no 100% guarantee that the
scale factor is integer on Mac (or other platforms when we support HiDPI
rendering on them). At least native APIs operate with float values.
Also, I wonder if we have to maintain the double precision for the scale
factor in native functions nativeSetScale/nativeGetScaleFactor (and in
Region.java, too). Would float values work fine?
src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
444 //Temporary disable this logic and use some magic constrain.
457 return getMaxTextureSize() / (getDevice().getScaleFactor() * 2);
I believe that this workaround is unrelated to the core retina-support
fix and should be omitted from it.
--
best regards,
Anthony
On 3/26/2013 19:33, Sergey Bylokhov wrote:
Hello,
Please review the fix for jdk 8.
Change adds initial support of hidpi(mostly on 2d side). In the fix
scale was added to the surface data/CGraphicsDevice /CGLLayer. This
scale factor maps virtual coordinates to physical pixels.
This change doesn't add support of hidpi to aqua l&f and doesn't add
support of dynamic change of scale factor.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
Webrev can be found at: http://cr.openjdk.java.net/~serb/8000629/webrev.06
--
Best regards, Sergey.
