[OpenJDK 2D-Dev] Review request for 8069348 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D

Alexander Scherbatiy alexandr.scherbatiy at oracle.com
Tue Nov 24 13:07:24 UTC 2015


  Could you review the updated fix:

  - 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 
  - The test which uses copyArea() method for VolatileImage is added. I 
left the test which moves internal frames for the Swing testing purposes.


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.

More information about the 2d-dev mailing list