[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] [9] request for review: 8040617: macosx : Large JTable cell results in a OutOfM
From:       Phil Race <philip.race () oracle ! com>
Date:       2014-08-25 18:35:39
Message-ID: 53FB81FB.7040203 () oracle ! com
[Download RAW message or body]

Ditto.

-phil.

On 08/22/2014 08:32 AM, Sergey Bylokhov wrote:
> Hi, Andrew.
> The fix looks good to me.
> Thanks.
>
> On 22.08.2014 19:28, Andrew Brygin wrote:
>> 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.
>>>
>>>
>>
>
>

[prev in list] [next in list] [prev in thread] [next in thread]