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.gra...@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
