[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] HiDPI support issues on Windows
From:       Anton Tarasov <anton.tarasov () jetbrains ! com>
Date:       2016-10-17 10:03:35
Message-ID: b92ef5b0-7069-f65c-90e9-43d9f119d6c4 () jetbrains ! com
[Download RAW message or body]

Thanks a lot, Jim! This sheds light on the subject and really sounds 
promising.

Anton.

On 10/6/2016 9:31 PM, Jim Graham wrote:
> Ah, I see.
>
> There are a lot of mistaken assumptions in the rendering there. It's 
> not just line thickness, it is assumptions about stroke control and 
> positioning of strokes.
>
> The biggest issue seems to be that developers (including our own 
> internal Swing developers who heard this lecture from me decades ago, 
> but ignored it because it was inconvenient and not yet relevant at the 
> time) who use the integer-based draw commands assume that their lines 
> are centered on the pixel that they are naming.  In other words "if I 
> draw a line along x=5 then I am telling the system to fill all the 
> pixels with an X coordinate of 5", but that is not what that drawing 
> request is asking for.  The coordinates are at pixel edges and it is 
> an artifact of our fill/stroke rules and stroke control hinting that 
> has made this work out at 1:1 scaling.  As soon as you scale you can 
> see the issues.  We used to only scale for printing, but now we are 
> starting to scale for the screen.
>
> g.drawRect(0,0,w-1,h-1) is a completely disfunctional way to outline a 
> component with any settings other than 1:1 coordinates and 
> STROKE_CONTROL on.  I've been mentioning this for years (going on 
> decades now), but Swing was addicted to that boilerplate for drawing a 
> border.  Thankfully, FX and its CSS-focused skinning has gone with a 
> different mechanism (primarily most FX components are outlined using 
> successive fills - optimized in implementation to avoid overdrawing - 
> rather than using strokes based on mistaken assumptions about where 
> the line is drawn).
>
> In particular, the line in that example g.drawRect(0,0,w-1,h-1) 
> technically occurs at the following coordinates:
>
> outer part of outline goes from 0.0-0.5,0.0-0.5 to w-1+0.5,h-1+0.5
>    (i.e. -0.5,-0.5 to w-0.5,h-0.5)
> inner part of outline goes from 0.0+0.5,0.0+0.5 to w-1-0.5,h-1-0.5
>    (i.e. +0.5,+0.5 to w-1.5,h-1.5)
>
> At a high enough scale you can see the stroke starting to separate 
> from the fill on the right and bottom edges where the closest it gets 
> to the edge is 0.5 scaled coordiantes.  That rounds to 0 for 1:1 and 
> with the biasing from STROKE_CONTROL, but at higher resolutions it 
> becomes a non-zero number of pixels.
>
> Even at 1:1 scale if you follow our filling rules explicitly (which 
> would require setting STROKE_CONTROL to PURE) then that would fill the 
> rows at y=-1 and y=h-2 and the columns at x=-1 and x=w-2, which is not 
> what you want at all. Setting STROKE_CONTROL on allows us to bias the 
> location of the stroke a little and it ends up filling the correct 
> pixels as a side effect (though STROKE_CONTROL is meant to achieve 
> consistency in strokes, it also ends up shifting the line by enough 
> that the fill rules choose different pixels in this case).  The 
> STROKE_CONTROL=on version of the path is assumed to be 
> (0.25,0.25,w-0.75,h-0.75) because we snap all coordinates in a 
> stroke-controlled non-AA path to the nearest location that is 
> 0.25,0.25 within a pixel.  This snapping to a consistent sub-pixel 
> location biasing at 0.25 was chosen because line widths grow more 
> evenly at that offset, but it offsets the outline enough so that the 
> outline considered for filling becomes:
>
> outer part of outline goes from 0.25-0.5,0.25-0.5 to 
> 0.25+w-1+0.5,0.25+h-1+0.5
>    (i.e. -0.25,-0.25 to w-0.25,h-0.25)
> inner part of outline goes from 0.25+0.5,0.25+0.5 to 
> 0.25+w-1-0.5,0.25+h-1-0.5
>    (i.e. +0.75,+0.75 to w-1.25,h-1.25)
>
> which renders the rows columns at 0 and wh-1 at a 1:1 scale using our 
> fill rules.  Note that if you scale high enough you can still see 
> separation between fill and outline, but the gap is only 0.25 scaled 
> coordinates so it would take a scale of at least 4x to see it.
>
> The technically accurate way to render the first/last 
> pixel/1-unit-coordinate boundary of a component would be to 
> drawRect(0.5,0.5,w-1,h-1) (with no stroke control set) which would 
> place the rectangle at the following coordinates:
>
> outer part of outline goes from 0.5-0.5,0.5-0.5 to 
> 0.5+w-1+0.5,0.5+h-1+0.5
>    (i.e. 0,0, to w,h)
> inner part of outline goes form 0.5+0.5,0.5+0.5 to 
> 0.5+w-1-0.5,0.5+h-1-0.5
>    (i.e. 1,1 to w-1,h-1)
>
> which completely encloses the first/last row/column of pixels on a 1:1 
> coordinate system and accurately covers the first/last N pixels in any 
> arbitrary N-scaled coordinate system.  The rounding for scales like 
> 1.5 still might not work out the way you wanted, but at least the 
> exact geometry is consistent with respect to the placement of pixels.  
> With AA you will get a consistent border all around if w,h are snapped 
> to a pixel size, but with non-AA then rounding error might lead to an 
> extra pixel on one pair of sides. I haven't done the analysis to see 
> how the above technique would be affected by STROKE_CONTROL because 
> really what you are looking for is to render the a consistent edge 
> around the component and so successive fills as is done with most of 
> our CSS skinning files in FX is a better solution overall. There are 
> just too many considerations in filling to make it worthwhile for 
> simple rectangular regions...
>
>                 ...jim
>
> On 10/4/16 1:46 PM, Anton Tarasov wrote:
>> On 10/4/2016 11:30 PM, Jim Graham wrote:
>>> I wasn't familiar with the test code for this particular case.  Is 
>>> it in a bug report somewhere?
>> Jim, I'm re-attaching it (it was in my first e-mail).
>>
>> Thanks,
>> Anton.
>>
>>>
>>>             ...jim
>>>
>>> On 10/4/16 1:01 PM, Anton Tarasov wrote:
>>>> Also, the problem with primitives rendering 
>>>> (http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) 
>>>> is
>>>> still there. But it seems to relate to line-thikness 
>>>> (border-thickness) rounding inaccuracy. What we can do with
>>>> that?...
>>

[prev in list] [next in list] [prev in thread] [next in thread]