Looks fine to me.

On 24.11.15 16:07, Alexander Scherbatiy wrote:

  Hello,

  Could you review the updated fix:
    http://cr.openjdk.java.net/~alexsch/8069348/webrev.01/

  - The given image sizes are transformed in the SG2D.doCopyArea method.
The copyArea() methods are updated accordingly.
  - OGLSurfaceData.copyArea() method is updated to process scaled
transforms.
  - The test which uses copyArea() method for VolatileImage is added. I
left the test which moves internal frames for the Swing testing purposes.

  Thanks,
  Alexandr.


On 11/20/2015 6:59 PM, Jim Graham wrote:
In terms of consolidating the code...

Since SD.copyArea is an internal API, we could simply specify that it
takes pixel coordinates and assumes COPY semantics so it is up to SG2D
to verify the transform and compState and perform appropriate
coordinate transformations before asking the SD to do the dirty work.
I'm not sure why we left so much veto power up to the SD class there...

            ...jim

On 11/20/15 7:38 AM, Sergey Bylokhov wrote:
On 20.11.15 14:49, Alexander Scherbatiy wrote:

Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8069348
   webrev: http://cr.openjdk.java.net/~alexsch/8069348/webrev.00

   For some reasons Blit operation does not properly work in the
SunGraphics2D.copyArea() method
   with scaled transform neither on Windows nor on Mac OS X.
   I have filled an issue on it: JDK-8143392 SunGraphics2D.copyArea()
does not properly handle Blit operation

Interesting.


   The current solution updates D3DSurfaceData.copyArea() to handle
scaled graphics in the same way
   as it has been already done for the CGLSurfaceData (see JDK-8000629
[macosx] Blurry rendering with Java 7 on Retina display).

Note that this fix does not help ogl on windows right? because on
windows the usual ogl blit should be used since the fix for retina was
osx specific. Or it works properly?


   May be there is a way to avoid the code duplication: put it to some
SurfaceDataUtils class (it also
   requires adding parent copyArea() method to BufferedRenderPipe) or
something else. I am not sure about the best option.

This is up to the 2d team, but I think yes, it will be better to move it
somewhere because after the current fix the different pipelines will
behave differently on different platforms for a different
transformations =(



   Thanks,
   Alexandr.






--
Best regards, Sergey.

Reply via email to