I need one more reviewer/+1... anyone? -- Scott K.
Begin forwarded message: > From: Scott Kovatch <scott.kova...@oracle.com> > Subject: Re: Review: Remove private API from graphics code > Date: September 4, 2012 8:16:03 AM PDT > To: Phil Race <philip.r...@oracle.com> > Cc: "awt-...@openjdk.java.net" <awt-...@openjdk.java.net>, 2d-dev > <2d-dev@openjdk.java.net>, "macosx-port-...@openjdk.java.net OS X" > <macosx-port-...@openjdk.java.net> > > 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. > > -- Scott > > > On Aug 31, 2012, at 11:50 AM, Phil Race <philip.r...@oracle.com> wrote: > >> The recommendation is to restore the graphics state rather than inverting :- >> >> https://developer.apple.com/library/mac/#documentation/graphicsimaging/conceptual/drawingwithquartz2d/dq_affine/dq_affine.html >> >> "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." >> >> -phil. >> >> On 8/31/2012 11:16 AM, Phil Race wrote: >>> Scott, >>> >>> 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. >>> >>> -phil. >>> >>> I am not sure why they are not used but it >>> On 8/31/2012 10:45 AM, Scott Kovatch wrote: >>>> http://cr.openjdk.java.net/~skovatch/7187834/webrev.00/ >>>> >>>> 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.kova...@oracle.com >>>> Santa Clara/Pleasanton, CA >>>> >>>> >>> >> >
