[OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip is ignored during surface->sw blit

Prahalad kumar Narayanan prahalad.kumar.narayanan at oracle.com
Mon Feb 22 08:57:21 UTC 2016

Hello Everyone, 2D-Dev Group

I continued to inspect the bug : JDK-8044788: [D3D] Clip is ignored 
during Surface > Sw Blit issue.
Link : https://bugs.openjdk.java.net/browse/JDK-8044788

Here is a quick brief on root cause, solutions experimented and the 
webrev link for review.
Kindly go through each of these items and provide your review so that we 
could check-in the bug fix.

Root Cause:
1. D3DSurfaceToSw Blit does not pass clip value to the native cpp interface
2. Even if the clip were to be passed through JNI, the native interface 
ignores the clip because it uses d3d's StretRect API.
3. Henceforth, in the current implementation, clipping in SurfaceToSw 
usecase will work ' only ' for Rect bounds provided proper src(x, y), 
dst(x, y), width and height are provided.
4. It can be noted that : the proper src(x, y), dst(x, y) are also not 
calculated considering the intersection of these rectangles with the 
clip bounds.

Different Solutions & Results
1. Three solutions are feasible to fix this issue:
         a. Solution 1: Convert the input Surface to Sysmem image, 
followed by regular Blit. To optimize this further, the conversion can 
be taken up only for Shape clips.
         b. Solution 2: Using existing classes in D3DBlitLoops, execute 
SwToSurface (copy dest to accel Surface), SurfaceToSurface (supports 
clip), SurfaceToSw (full copy) in order.
         c. Solution 3: Modify the native side interfaces to accept clip 
and execute Solution2 's logic in native code.
2. Upon various experiments, Solution 1 has been found to be faster than 
the rest.
         a. This can be attributed to fewer draw /or copy iterations 
compared to the other two solutions.
         b. In addition to the above fact, the code retains the same 
approach as used by the OGL pipeline making it easier to understand.

Webrev Link: http://cr.openjdk.java.net/~psadhukhan/prahlad/webrev.00/
Sufficient comments have been added so that developers could easily get 
understanding of the issue and solution checked in.

Thank you
Have a great day

Prahalad N.

Subject: 	Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip 
is ignored during surface->sw blit
Date: 	Wed, 15 Apr 2015 16:17:37 +0300
From: 	Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
To: 	prasanta sadhukhan <prasanta.sadhukhan at oracle.com>, 
2d-dev at openjdk.java.net

Hi, Prasanta.
The same approach was used in OGL pipeline for the reason. Because we
use glReadPixels and there is no way to apply the clip. So we read
pixels to the temporary buffer and apply the clip later. Can you
additionaly investigate is it possible to apply the clip in d3d directly
or not?

Note that this [1] comment is not correct in d3d, because d3d have only
one direct blit D3d surface -> SW which is D3DSurfaceToSwBlit(IntArgb,
ST_INT_ARGB), all other blits will be done via temporary buffer in

>  523         // We can convert argb_pre data from D3d surface in two
> places:
>  524         // - During D3d surface -> SW blit
>  525         // - During SW -> SW blit
>  526         // The first one is faster when we use opaque D3d
> surface, because in
>  527         // this case we simply skip conversion and use color
> components as is.
>  528         // Because of this we align intermediate buffer type with
> type of
>  529         // destination not source.

On 15.04.15 11:57, prasanta sadhukhan wrote:
> Hi,
> I would like a review for a solution of this bug in jdk9.
> The clip was ignored during surface->sw blit in d3d pipeline. The fix
> is to use the clip parameter to calculate the blit coordinates correctly.
> Bug:https://bugs.openjdk.java.net/browse/JDK-8044788
> webrev:http://cr.openjdk.java.net/~psadhukhan/8044788/webrev.00/
> Regards
> Prasanta

Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20160222/e3a3ba89/attachment.html>

More information about the 2d-dev mailing list