[OpenJDK 2D-Dev] [9] Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl

Jim Graham james.graham at oracle.com
Sat Nov 15 02:57:01 UTC 2014


I see what you are saying, if we get in here with a native destination 
surface at all then we aren't likely to find a native maskblit.

I don't think bicubic and BG operations are that common, though.  And I 
don't think they are common enough to warrant creating a new pathway to 
potentially create an unverified Region.

			...jim

On 11/14/14 6:32 PM, Sergey Bylokhov wrote:
> ----- james.graham at oracle.com wrote:
>
>> By "this code" I mean the new code that constructs a clip region from
>> an
>> edges array.  That only happens if the tests at 478 and 491 fail and
>> those have nothing to do with bicubic or BG operations.
>> BG operations get folded into INT_RGB earlier in the method so we are
>> actually more likely to end early at line 499 and not need the edges
>> array.  bicubic has absolutely no bearing on whether we make it past
>> line 499 either.
>
> We end at line 499 only if we find a nativemask blit, which is supported by TransformHelper directly, this is not the case for most of our java loops: sw->oglsurface, surface->oglsurface. So all blits which are filter out in OGLDrawImage,renderImageXform()(note it filter out BG,bicibic,bilinear,xorComp,customComp) will use TransformHelper->egdes->blit, I guess this is not a rare case.
>
>
>>
>> BG or bicubic may force us to not use a hw loop on a hw surface, but
>> they have no bearing on whether we make it down to the edges array
>> code...
>>
>> 			...jim



More information about the 2d-dev mailing list