[OpenJDK 2D-Dev] [9] request for review: 8040617: macosx : Large JTable cell results in a OutOfMemoryException
Phil Race
philip.race at oracle.com
Mon Aug 25 18:35:39 UTC 2014
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.
>>>
>>>
>>
>
>
More information about the 2d-dev
mailing list