On 03/27/13 20:12, Sergey Bylokhov wrote:
On 3/27/13 6:52 PM, Anthony Petrov wrote:
(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.
Yes, but it is unclear how we could convert points to pixels when the
scale factor of 1.5, for example. If we get xx.xx scale in the future,
additional work will be required. For now the simplest way just used.
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?
I use double precision everywhere, because SunGraphics2D in the
transform uses double precision, and I cast double to int where it is safe.
That makes sense. Thanks for the clarifications.
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.
Without this change, applets unsuitable for use in hidpi mode under
quartz-debug(our sqe use it also). Moreover I assume, that the display
bounds constrain is incorrect anyway.
This only applies to a few specific applets, and the problem is not
directly related to HiDPI support because you'll run into a similar bug
when running with a LoDPI native resolution of, say, 640x480 or 800x600.
Therefore I believe that this particular change deserves a separate CR.
Could you file one please and remove the change from your current fix?
--
best regards,
Anthony
--
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.
