[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] Review Request: (JDK-8044788) [D3D] clip is ignored during surface->sw blit
From:       Sergey Bylokhov <Sergey.Bylokhov () oracle ! com>
Date:       2016-02-24 11:45:46
Message-ID: 56CD97EA.9030904 () oracle ! com
[Download RAW message or body]

Hi, Prahalad.
The fix looks good in general. I have only one question:
In the complexClipBlit() you have this code:
552 // Type- indicates the pixel format of Sysmem based BufferedImage.
553 // Native side D3D interface supports copying surface contents to
554 // ST_INT_ARGB, ST_INT_ARGB_PRE and other pixel formats
555 final int type = typeval == D3DSurfaceData.ST_INT_ARGB_PRE ?
556 BufferedImage.TYPE_INT_ARGB_PRE :
557 BufferedImage.TYPE_INT_ARGB;

This code was copied from the OGL version of the fix and it have two 
assumptions:
- The type of the native texture can be ST_INT_ARGB_PRE, or can contains 
"other"(???) value. Please take a look to the OGLBlitLoops.java code. In 
OGL we register two different blits:
OGLSurfaceToSwBlit blitSurfaceToIntArgbPre =
new 
OGLSurfaceToSwBlit(SurfaceType.IntArgbPre,OGLSurfaceData.PF_INT_ARGB_PRE);
// surface->sw ops
new OGLSurfaceToSwBlit(SurfaceType.IntArgb,OGLSurfaceData.PF_INT_ARGB),
blitSurfaceToIntArgbPre,

So in OGL when the blit is called the type can be PF_INT_ARGB_PRE or 
PF_INT_ARGB. This is why we have "if" statement in the complexClipBlit.

  - The second assumption is that the native code is able to copy the 
d3d texture to the system memory and do conversion on the fly. The ogl 
code have such conversion(argb_pre is converted to argb in the 
OGLBlitLoops.c in the flip() method). Do you know our native d3d part is 
able to do the same? If yes, then we should register separate blits in 
D3DBlitLoops to cover different source/destination and change the "if".

On 22.02.16 11:57, Prahalad kumar Narayanan wrote:
> 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@oracle.com>
> To: 	prasanta sadhukhan <prasanta.sadhukhan@oracle.com>,
> 2d-dev@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
> D3DGeneralBlit.
>
> [1]
>>  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.
>
>
>
>
>
>
>


-- 
Best regards, Sergey.
[prev in list] [next in list] [prev in thread] [next in thread]