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
