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
