[OpenJDK 2D-Dev]  Review Request: 8059942 Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl
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.
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
>> 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
More information about the 2d-dev