<Swing Dev> [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used

[Alexandr Scherbatiy]

Thank you. I see that using the integer device-pixel translations 
preserves the component painting in the same way for floating point scales.

Could you review the updated fix:
   http://cr.openjdk.java.net/~alexsch/8162350/webrev.03

   - translation adjustment is removed
   - Region.clipRound() is used for pixels coordinates rounding.

   Thanks,
   Alexandr.

On 11/16/2016 1:52 AM, Jim Graham wrote:
> Let me clarify something...
>
> On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote:
>>   Let's consider the following use case:
>>   scale = 1.5
>>   A component calls fillRect(1, 1, 1, 1).
>>   This is (1.5, 1.5, 3.0, 3.0) in the device space
>>   which fills  (1, 1, 3, 3) and covers 2x2 pixels
>
> Agreed.
>
>>   Now the area (1, 1, 1, 1) needs to be repainted
>>     create a backbuffer
>>     translate(-1, -1) // move the top left corner of the area to the 
>> zero point
>>     draw the component into the backbuffer:
>>       fillRect(1, 1, 1, 1) -> after translation fillRect(0, 0, 1, 1) 
>> -> after scaling  (0.0, 0.0, 1.5, 1.5 ) in the
>> device space
>>       which fills (0, 0, 1, 1) and covers 1x1 pixels
>
> If you did g.setTransform(identity), g.translate(-1, -1), (then 
> restore the scale) then the analysis is as follows:
>
> g.setTransform(identity) => [1 0 0] [0 1 0]
> g.translate(-1, -1) => [1 0 -1] [0 1 -1]
> g.scale(1.5, 1.5) => [1.5 0 -1] [0 1.5 -1]
> g.fillRect(1, 1, 1, 1)
>     => coordinates are (1.5-1, 1.5-1, 3-1, 3-1)
>     => (.5, .5, 2, 2)
>     => fills (0, 0, 2, 2)
>     => which covers 2x2 pixels
>
> If you did g.translate(-1, -1) on the scaled transform then the 
> analysis is as follows:
>
> g.transform is [1.5 0 0] [0 1.5 0]
> g.translate(-1, -1) is [1.5 0 -1.5] [0 1.5 -1.5]
> g.fillRect(1, 1, 1, 1)
>     => coordinates are (1.5-1.5, 1.5-1.5, 3-1.5, 3-1.5)
>     => (0, 0, 1.5, 1.5)
>     => fill (0, 0, 1, 1)
>     => covers 1x1 pixels
>
> The second operation is what you are describing above and that would 
> be an inappropriate way to perform damage repair because you used a 
> scaled translation which did not result in an integer coordinate 
> translation.
>
> Please re-read my previous analysis that shows what happens when you 
> use integer device-pixel translations which are translations that 
> happen using integers on a non-scaled transform.  Note that you can 
> add a scale *AFTER* you apply the integer device pixel translation and 
> it will not affect the integer-ness of the translation.  You can see 
> above that the difference in how the translate command is issues 
> affects where the translation components of the matrix end up being 
> -1,-1 or -1.5,-1.5...
>
>             ...jim