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

[Jim Graham]

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.
>>
>
>