Hello,
I have filled additional issues which has been discussed on the review:
JDK-8076545 Text size is twice bigger under Windows L&F on Win 8.1
with HiDPI display
JDK-8142966 Wrong cursor position in text components on HiDPI display
JDK-8142961 Position, size and distance scaling for HiDPI graphics
support
JDK-8142963 Better transformImage support for HiDPI images
JDK-8069348 SunGraphics2D.copyArea() does not properly work for
scaled graphics
JDK-8142965 Consider the case where MRI can contains VolatileImage
Thanks,
Alexandr.
On 11/12/2015 2:33 AM, Jim Graham wrote:
Hi Alexandr,
On 11/11/15 3:08 AM, Alexander Scherbatiy wrote:
On 11/10/2015 10:41 PM, Jim Graham wrote:
In drawHiDPIImage, in the VolatileImage case you ignore the transform,
but I suppose that is OK because you pass it through to the
scaleImage() case. However if it came in with a transform then the
asserts at the top of scaleImage may fail? Maybe it would be better
to actually handle the "non-0,0,iw,ih" case rather than assert that it
doesn't exist?
The only case where xform is not null is the drawImage(img, xform,
observer) method which always use zero x, y and the same src and dst
width/height.
Could we move the full support for a resolution variant
transformation to a separate fix?
Ah, sorry, I was reading the old webrev.02 and also mixing up
s[xy][12] (which are scaled) with d[xy][12] (which are the ones being
compared). You are correct there.
The new version in webrev.03 is a little clunky with having to modify
the current transform, but it looks correct.
BIGC.getConfig() - I don't see where you put the scale into the BIGC
when you create it. Shouldn't the constructor with scales be used at
line 73?
It is updated in the latest webrev:
http://cr.openjdk.java.net/~alexsch/8073320/webrev.03
which has been sent to the review:
http://mail.openjdk.java.net/pipermail/2d-dev/2015-November/005814.html
Found the webrev.03 and it is already fixed as you say.
SGE.getScaleFactor() - suggestion: perhaps ignore an optional final
suffix "x" in the regular scale case so that they can say "=3.0x" to
mean the same as "=3"?
It should also be updated in the latest webrev.
Found it. Looks good...
Looks almost good to go from my perspective. What is the plan for
Swing testing and fixing those bugs?
The latest fix looks good to go. I was hoping to build it and test
some swing apps, but I don't have a decent build environment ready to
go yet. We need to be proactive about understanding how this affects
Swing so that we can inform our developers about any changes they may
need to make to look good under HiDPI and/or modify the approach to
handle it ourselves...
...jim
