Looks ok to me.
Regards
Prasanta
On 11/6/2015 3:50 PM, Jayathirth D V wrote:
Hi Prasanta,
As discussed, only in case of write_IDAT there is finally block which
calls ios.finish() which internally calls seek() with improper
startPos. In other cases we are not trying to access improper startPo
In drawHiDPIImage, in the VolatileImage case you ignore the transform,
but I suppose that is OK because you pass it through to the scaleImage()
case. However if it came in with a transform then the asserts at the
top of scaleImage may fail? Maybe it would be better to actually handle
the "non
I think this can be good to go, but file some issues for further
investigation:
- scaling in applyShape()
- GDK_DPI_SCALE (though it may get handled under the other bug, maybe
add a comment there)
- Other Linux DPI properties to support
And while we probably don't need an issue submitted unti
On 11/10/15 5:07 AM, Alexander Scherbatiy wrote:
On 11/6/15 2:00 AM, Alexander Scherbatiy wrote:
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8137571/webrev.03/
- pixbuf is freed in the awt_Robot.c
- screenWidth/Height is rescaled in the XToolkit.initScre
On 11/7/2015 3:56 AM, Jim Graham wrote:
It looks like the only remaining issues are:
- Should we scale the origin of the screens so that they remain adjacent?
The Toolkit defines only methods that allows to get size of the the
primary screen and screen insets which are rescaled in the pro
