<AWT Dev> [OpenJDK 2D-Dev]  Review request for 8073320 Windows HiDPI Graphics support
alexandr.scherbatiy at oracle.com
Fri Nov 13 16:46:21 UTC 2015
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
JDK-8142963 Better transformImage support for HiDPI images
JDK-8069348 SunGraphics2D.copyArea() does not properly work for
JDK-8142965 Consider the case where MRI can contains VolatileImage
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
>> 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] (which are scaled) with d[xy] (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:
>> which has been sent to the review:
> 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...
More information about the awt-dev