[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] HiDPI support issues on Windows
From:       Jim Graham <james.graham () oracle ! com>
Date:       2016-09-30 20:30:33
Message-ID: 38cfa226-bf2a-a2c3-7bf1-5727c87256dc () oracle ! com
[Download RAW message or body]



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


[prev in list] [next in list] [prev in thread] [next in thread]