<AWT Dev> Review: Remove private API from graphics code
scott.kovatch at oracle.com
Tue Sep 4 08:16:03 PDT 2012
I posted a new webrev at http://cr.openjdk.java.net/~skovatch/7187834/webrev.01/
In ImageSurfaceData, it looks like we are trying to get back to a pure CTM (i.e., no transform of any kind applied.) before we draw the image. We have already saved the state, but saving the state doesn't reset it. That's why there are extra gyrations to invert and concat the inversion. In QuartzRenderer.m the information you found applies, so I'm just using that now.
These changes fix the printing bugs in Java2Demo that I saw with the first webrev.
On Aug 31, 2012, at 11:50 AM, Phil Race <philip.race at oracle.com> wrote:
> The recommendation is to restore the graphics state rather than inverting :-
> "Quartz also provides an affine transform function that inverts a matrix, |CGAffineTransformInvert|. Inversion is generally used to provide reverse transformation of points within transformed objects. Inversion can be useful when you need to recover a value that has been transformed by a matrix: Invert the matrix, and multiply the value by the inverted matrix, and the result is the original value. You usually don’t need to invert transforms because you can reverse the effects of transforming the CTM by saving and restoring the graphics state."
> On 8/31/2012 11:16 AM, Phil Race wrote:
>> These files were added by Bino to support printing. Quartz isn't used
>> except for printing in JDK 7, so as I understand it, testing on-screen in
>> Java2Demo should not exercise this code. I'm surprised that you saw
>> it being exercised. Did you do any printing testing ?
>> The matrix inversion seems unlikely to be applied to any non-invertible
>> matrices, so that's fine, but I wonder if you have lost precision here
>> due to floating point inaccuracies ?
>> If you originally had a simple scale or identity, rotated it, and then
>> applied the inverse to unrotate it, do you really end up with exactly
>> the same results. The more you do this the more inaccuracies creep in,
>> which may be part of the reason for the original approach.
>> I find it a little hard to believe that there isn't a direct public way to
>> restore a transform.
>> The changes for mountain lion are safe for snow leopard I presume?
>> I believe the builds still happen on snow leopard.
>> Also this should have been sent to 2d-dev, not awt-dev.
>> These files, APIs, and printing are all 2D, not awt.
>> I am not sure why they are not used but it
>> On 8/31/2012 10:45 AM, Scott Kovatch wrote:
>>> This is based on the patch submitted by Marco Dinacci. I had to modify it a bit to get it to compile against 7u-dev, but nothing major.
>>> The changes in ImageSurfaceData.h were needed as a result of my use of Xcode 4.4.1 on Mountain Lion.
>>> I ran the Java2Demo and don't see any problems. I paid close attention to the Images tab, since it looks like this code is heavily used by it.
>>> -- Scott K.
>>> Scott Kovatch
>>> scott.kovatch at oracle.com
>>> Santa Clara/Pleasanton, CA
More information about the awt-dev