[OpenJDK 2D-Dev] [9] Review Request: 7188942 Remove support of pbuffers in OGL Java2d pipeline

[Phil Race]

+1

-phil.
On 07/02/2015 01:04 PM, Sergey Bylokhov wrote:
> On 18.06.15 9:30, Jim Graham wrote:
>> CGLVSM.java:
>>
>> In the constructor we claim to accelerate any surface if 
>> CAPS_EXT_FBOBJECT is present, but CGLGC.java has a test to reject 
>> BITMASK. Shouldn't the 2 perform the same test?
>
> Yes you are right. After additional investigation I found that we 
> incorrectly handle bitmask accelerated surface and we should use 
> software surface in this case(the test is added).
> The corresponding code in XXXVolatileSurfaceManager was updated:
> http://cr.openjdk.java.net/~serb/7188942/webrev.03
>
> I think there are an opportunity to merge some of these files to some 
> general version, because most of them simply were copied from each 
> other. I'll take a look to this.
>
>>
>>
>>             ...jim
>>
>> On 6/16/15 6:01 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk9.
>>>
>>> The reason of the removing is a general deprecation of pbuffers, and a
>>> lack of their support in the java2d, because for a long time pbuffers
>>> were not used by default.
>>> Attempts to disable FBO(which are used by default), and enable the
>>> pbufferes will cause a different crashes in different places on all our
>>> platforms(mac,lin,win).
>>>
>>> Change description:
>>>   - Possibility to create a VolatileImage on top of pbuffers was
>>> removed. FBO and Textures are supported only.
>>>   - "-Dsun.java2d.opengl.fbobject" now totally disable accelerated
>>> volatile images(BufSurfaces will be used instead). But it does not
>>> affect manageable images.
>>>   - CAPS_STORED_ALPHA is removed because it was used to check is 
>>> pbuffer
>>> is able to store alpha or not.
>>>
>>> Note that pbuffers are still used to get some information from the
>>> opengl on the start. I plan to replace these usage later.
>>>
>>> Some related questions:
>>>   - Does anybody know about AccelTypedVolatileImage, how it was planned
>>> to use? It seems that the work on it was not completed and its usage 
>>> can
>>> be simply removed/replaced.
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7188942
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/7188942/webrev.01
>>>
>>> -- 
>>> Best regards, Sergey.
>>>
>
>