On 21.05.15 22:59, Jim Graham wrote:
I'm curious about bufferClip in the converter routine. Does that help? Since we clip when we blit back to the destination in the last line, we don't necessarily need to clip the intermediate operation. I suppose it could save time, but if it is a rect clip then I would think the entire op would already be trimmed to just the size of the clip. And if it is a complex clip then there is a tradeoff between operating on the excluded pixels and how long it takes to create the translated clip and how much overhead there is in enumerating it inside the performop blit. Best to leave it for now, but I thought I would float that issue...
This clip is useful, because in general we can use some custom/slow compozite here, and it will be better to minimize it usage.

Looks good, modulo the indenting issue...

            ...jim

On 5/21/15 6:22 AM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk9.
Our blits machinary in case of absent of direct/general blits will use
the AnyBlit, which uses surface.getRaster method. This method is not
implemented in OGL surfaces, so we must have some blit, which covers all
possible combinations of source/destination/composite.

In the fix for JDK-7124347[1] the new OGLAnyCompositeBlit was added, and
this new blit covers situation, when we cannot call getRaster on
destination and must read it to the temporary buffer. But it does not
take into account that the same problem exists for the source. If the
source surface is OpenGLSurface and xor composite is used we should copy
it to the temporary buffer also.

In this fix I added some parameters, which configure OGLAnyCompositeBlit
for the case when some kind of ogl source is passed.


[1] https://bugs.openjdk.java.net/browse/JDK-7124347

Bug: https://bugs.openjdk.java.net/browse/JDK-8061831
Webrev can be found at: http://cr.openjdk.java.net/~serb/8061831/webrev



--
Best regards, Sergey.

Reply via email to