Hi Jim,
Thank you for the details! This gives a clue.
Anton.
On 10/2/2016 10:10 PM, Jim Graham wrote:
After looking into the code in RepaintManager and re-reading
Alexander's message again I can see how it describes what is going on
more clearly.
Fixing the rounding errors doesn't necessarily require avoiding use of
the intermediate image for damage repair, you just have to make sure
that you use the incoming xywh as suggestions for what needs to be
redrawn, but instead determine exact pixels that you will repaint
(usually floor,floor,ceil,ceil to "round out" the area), and then use
those pixel-precise locations instead of passing along the integers
that came from the repaint requests and hoping for the right
rounding. The problem is that a number of the interfaces used by the
RepaintManager take integers and hide a scale from the caller so we
need to either work around their implicit scale, or possible create
internal variants that let us work in pixels.
In other words, the typical boilerplate for intermediate image damage
repair would be:
// repainting x,y,w,h
img = make image (w,h)
g = img.getGraphics()
g.setClip(x,y,w,h)
g.translate(-x,-y)
component.paint(g)
destination.drawImage(img, x,y)
but that boilerplate only works if x,y are exact pixel coordinates,
but since it is all being doing on a scaled graphics then x,y will
transform to arbitrary not-necessarily-integer locations and then all
bets are off.
Fixing this could either rely on using float interfaces wherever
available, or by undoing all of the implicit scales and working in
pixels, but being aware of the scale that is required for the
destination. Something like one of these boilerplates instead:
// repainting x,y,w,h integers using floats
float pixelx1 = floor(x * scaleX)
float pixely1 = floor(y * scaleY)
float pixelx2 = ceil((x+w) * scaleX)
float pixely2 = ceil((y+h) * scaleY)
int pixelw = (int) (pixelx2 - pixelx1)
int pixelh = (int) (pixely2 - pixely1)
// Note that the code currently asks the destination to make
// a compatible image of a virtual pixel size that is then
// scaled to match. A "make me an image of this many pixels"
// might be less cumbersome.
img = make image (ceil(pixelw / scaleX),
ceil(pixelh / scaleY))
g = img.getGraphics() // will be scaled already
// The following will use the translate(double, double) method
g.setClip(new Rectangle2D.Double(pixel* / scale*))
g.translate(-pixelx1 / scaleX, -pixely1 / scaleY)
component.paint(g)
// Since there is no drawImage(img, float x, float y)...
destination.translate(pixelx1 / scaleX, pixely1 / scaleY)
destination.drawImage(img, 0, 0)
// (restore transforms where needed)
That version uses floating point interfaces in a number of key places
(notably translate() calls are available as either int or double in
the Graphics and have to use the setClip(Shape) method to specify a
floating point rectangle), but a down side is that using those
interfaces means that you have a value that you know is at a pixel
boundary and you pass it in as "number / scale" only to have the code
in the Graphics immediately apply that scale and you end up with the
final result of "number / scale * scale" which might incur round-off
errors and end up being slightly off of a pixel.
In another approach, you could also kill all of the transforms and do
it more directly in pixels as in the following:
// repainting x,y,w,h integers using unscaled operations
// Some parts more cumbersome to undo the implicit scaling
// but it won't suffer from round-off errors when constantly
// scaling and unscaling through the various interfaces
// that have transforms built in
int pixelx1 = (int) floor(x * scaleX)
int pixely1 = (int) floor(y * scaleY)
int pixelx2 = (int) ceil((x+w) * scaleX)
int pixely2 = (int) ceil((y+h) * scaleY)
int pixelw = pixelx2 - pixelx1;
int pixelh = pixely2 - pixely1;
// Not sure if there is a mechanism for this since I think
// all of the interfaces to get a compatible image are
// designed to assume that the caller is not scale-aware.
img = make pixel-sized image (pixelw, pixelh)
g = img.getGraphics()
// assuming that g would be unscaled in this case, but
// if g is scaled, then g.setTransform(IDENTITY)
// translate by an integer amount, and then scale
g.setClip(pixelx1, pixely1, pixelw, pixelh)
g.translate(pixelx1, pixely1)
g.scale(scaleX, scaleY);
component.paint(g)
destinationg.setTransform(IDENTITY)
destinationg.drawImage(img, pixelx1, pixely1)
// (restore transforms where needed)
...jim
On 9/30/2016 1:30 PM, Jim Graham wrote:
On 9/30/16 3:22 AM, Alexandr Scherbatiy wrote:
The problem is that the RepaintManager draws a region to a buffered
image at first and draws the image after that to the
window.
Suppose the image has int coordinates and size (x, y, w, h) in the
user space. It should be drawn into the region with
coordinates (x, y, x+width, y+height) = (x1, y1, x2, y2).
If floating point UI scale is used (like 1.5) the region coordinates
are converted to values (1.5 * x1, 1.5 * y1, 1.5 *
x2, 1.5 * y2) in the dev space.
Now these coordinates need to be rounded and the process really
depends on the evenness or oddness of the start and end
coordinates. They both can be rounded to one side or to opposite.
Depending on this some lines near the drawn image
region can be not filled or just wrongly filled.
The repaint manager should compute the nearest pixel bounds outside of
the scaled repaint area, and then adjust the rendering to repaint all of
those pixels. You don't "round" here, you "floor,floor,ceil,ceil" (and
then worry how to present the clip region to the app so it can do the
right thing - probably by clipping to a Rect2D.Float() and letting the
integer g.getClipBounds() further round out the coordinates which means
extra paint calls, but at least you'll repaint all the dirty pixels and
they will be blitted to the right destination pixels if the code that
sends them to the screen is aware of the full resolution...)
...jim
