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
