On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote:
Were you seeing that happen? Because that would be a rendering bug in
fillRect...
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
Now the area (1, 1, 1, 1) needs to be repainted
Is that the area in device pixels or component scaled coordinates?
create a backbuffer
translate(-1, -1) // move the top left corner of the area to the zero point
Are you calling translate(-1,-1) on a scaled graphics or on a graphics that has
an identity transform set instead?
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
That is true if you are using scaled translates that don't line up on pixel bounds. I am suggesting that the repaint
code use only *INTEGER DEVICE PIXEL TRANSLATES* which don't have this problem...
Draw the backbuffer to the window at coordinates (1, 1)
At (1, 1) in the device pixel coordinate space or the scaled component
coordinate space?
The rectangle with size 1x1 pixels is drawn instead of the 2x2
It sounds like you were using scaled component coordinate space translations and blits which would cause the rendering
to change.
RepaintManager should only ever be using device pixel translates and do none of its set-up work in the scaled coordinate
space.
The result of translation, painting to the backbuffer and painting the
backbuffer from the requested point can differ
from just drawing from this point just because drawing from some point and
drawing the same thing from the zero point
can differ for the floating point scale.
They can only differ if you make the mistake of using scaled coordinate
translations to manage dirty areas and scrolling...
...jim
