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.
