On 03.07.15 0:55, Jim Graham wrote:
One last thing. The old test in the SurfaceManagers used to only
require FB_OBJECT for translucent types, the new test requires
FB_OBJECT for all types. Is that intentional?
Yes, there was an assumption that pbuffers always support opaque
types(translucent was supported by the fbo or pbuffer+CAPS_STORED_ALPHA)
...jim
On 7/2/15 1: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.
--
Best regards, Sergey.