Hi Sergey,
yes, we throw the OOME in a shared code, so other platforms with OGL are
affected as well.
I have updated the fix according to you suggestion, please take a look:
http://cr.openjdk.java.net/~bae/8040617/9/webrev.01/
Thanks,
Andrew
On 8/22/2014 6:47 PM, Sergey Bylokhov wrote:
Hi, Andrew.
It seems to me that the same bug exists on other platforms as well.
Probably we can move this check to the upper level(in the same way as
d3d in case of InvalidPipeException?)?
On 22.08.2014 18:34, Andrew Brygin wrote:
Hello,
could you please review a fix for CR 8040617?
Bug: https://bugs.openjdk.java.net/browse/JDK-8040617
Webrev: http://cr.openjdk.java.net/~bae/8040617/9/
The problem happens when we are trying to create an accelerated copy
for a buffered image with dimension exceeded GL_MAX_TEXTURE_SIZE.
An artificial OOME is thrown as an indicator of surface initialization
failure.
Suggested fix handles the exception in createManagedSurface() in
the same manner as it is handled in CGLVolatileSurfaceManager: we
return 'null' instead of accelerated surface data, that result of
using original surface data instead of accelerated.
Supplied regression test demonstrates the problem.
Please take a look.
Thanks,
Andrew.
