RFR: 8211294: [windows] TextArea content is blurry with 125% scaling

[Johan Vos]

On Thu, 24 Sep 2020 19:09:19 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

>> This PR aims to fix the blurriness to sometimes affects some controls (such as TextArea) in a scene when rendered with
>> a scaling factor that is not an integer (typically when viewed on a HiDPI screen with a 125%, 150% or 175% output
>> scaling).  Please note that regardless of what the JBS issue (and therefore the title of this PR) states, this does not
>> appear to be a Windows only issue as I have observed the same issue on Linux (Ubuntu 20.04).
>> The following conditions are necessary for the blurriness to appear, but do not guarantee that it will:
>> 
>> - The node, or one of its parents, must have set `Node::cacheProperty` to `true`
>> 
>> - The scaling factor (as detected automatically or explicitly set via glass.win/gtk.uiScale) must be a non integer number
>>   (e.g. 1.25, 1.5, 175)
>> 
>> - The effective layout X or Y coordinates for the cached node must be != 0;
>> 
>> Under these conditions, the translate coordinates for the transform used when the cached image for a node is rendered
>> to the screen may be non integer numbers, which is the cause for the blurriness.
>> Based on these observations, this PR fixes the issue by simply rounding the translate coordinates (using `Math.round`)
>> before the transform is applied in `renderCacheToScreen()` and as far as I can tell, it fixes the blurriness in all the
>> previously affected applications (both trivial test cases or with complex scenegraphs) and does not appear to introduce
>> other noticeable visual artifacts.  Still, there might be a better place somewhere else higher up in the call chain
>> where this should be addressed as it could maybe be the root cause for other rendering glitches, though I'm not yet
>> familiar enough with the code to see if it is really the case.
>
> Also, I don't really have an idea on how this could be tested other than visually, so I'm open to suggestions.

The visual representation corresponds with digits, so there can be tests that check if the numbers are what we expect
them to be.  It's good that this is not windows-only, so that it can be tackled on linux as well. But what is not clear
to me: does this require a physical HiDPI screen, or is setting the scale factor manually good enough to reproduce the
bug?

-------------

PR: https://git.openjdk.java.net/jfx/pull/308