Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

[Clemens Eisserer]

HI,

> As previously mentioned, I increased the RenderQueue buffer (see patchs at
> the end) to 4M (instead of 32K) and d3d & opengl get boosted.

It is great to see the tile-size improvements reach the other backends too :)

In case of the buffer size - I wonder is 4M really needed or was it an
arbitrary number (128x increase)?
The reason I ask is the overhead of a smaller RenderQueue (the Queue
flushes are process-local (actually a thread-switch & wait) and I am a
bit concerned about memory consumption of non-graphically intensive
applications (+4mb for e.g. a small swing app would be a big deal).

Best regards, Clemens

Re: [OpenJDK 2D-Dev] Initial implementation for batched AA-mask upload for xrender

[Sergey Bylokhov]

Hi, Clemens.
On 21/02/2018 23:41, Clemens Eisserer wrote:

It is still in prototype state with a few rough edges and a few
corner-cases unimplemented (e.g. extra alpha with antialiasing),
but should be able to run most workloads:
http://93.83.133.214/webrev/
https://sourceforge.net/p/xrender-deferred/code/ref/default/

It is disabled by default, and can be enabled with -Dsun.java2d.xr.deferred=true
Shm upload is enabled with deferred and can be disabled with:
-Dsun.java2d.xr.shm=false

What would be the best way forward?
Would this have a chance to get into OpenJDK11 for platforms eith
XCB-based Xlib implementations?
Keeping in mind the dramatic performance increase,
even outperforming the current OpenGL pipeline, I really hope so.


Thank you for contribution! If there is a chance to implement it soon(at 
an early test stage) then it is possible to push this to jdk11 and 
enable it by default to expose all possible issues. If no issues will be 
found, then we can release it as-is, otherwise we can disable it by 
default via property.


--
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

[Sergey Bylokhov]

Hi, Laurent.
On 05/03/2018 14:19, Laurent Bourgès wrote:
First Marlin 0.9.1 patch works well: no crash or bug with larger tiles 
128x64 even if d3d / opengl uses internally 32x32 texture caches.
Moreover xrender pipeline is the fastest compared to D3D (40% slower) or 
opengl (>250% slower) !


What types of GraphicsPrimitives were tested(in terms of java2d)? I 
guess that d3d/ogl may outperform other pipelines only in case of 
"native" blits, which are used in case of draw of cashed 
bufferedImage(OGL texture) or VolatileImage(FBO) to the window/volatile 
image(this also depends from the composite type and alpha).
In other cases it will be slower since it use an additional layer - 
RenderQueue, it would be good to compare xrender and gdi/X11.


Some unrelated question: it is interesting how xrender will work in Wayland.


Note 1. OGL is not officially supported on linux. We need to check ogl 
performance on macOS where it is used as a default pipeline.


Note 2. there are some other blit's related tiles like:
#define OGLC_BLIT_TILE_SIZE 128

Also please be care about different vendors:
OGLC_VENDOR_INTEL/OGLC_VENDOR_ATI/OGLC_VENDOR_NVIDIA because their 
native blits are implemented differently. The reason was in a 
performance of some OGL API(maybe this code is outdated).


I suggest to use some common testcases from J2DBench and SwingMark, so 
at some point later it will be possible to check other changes for 
possible regression, for example see:

https://bugs.openjdk.java.net/browse/JDK-8059944
Note that this fix in some cases decreased a performance by half but in 
other cases improved it by 25422.21%. You can see we can improve 
performance in one case but lose much more in another. This is why 
J2DBench is better because it can check all combinations of 
src/dst/composite/clip/size/etc..


Soory to insist but who could advice me and give me explanations on the 
RenderQueue & d3d / opengl backends.


I read JBS for RenderQueue buffering as I have several questions 
(asynchronous queue ?)

How to auto-tune such buffer capacity ?
It seems tricky as too small or too large buffers impacts performance as 
it depends on the GPU speed (drain the buffer).

Is there any design document ?


As far as I know there are no documents about tile tuning, most of 
decisions were made according to j2dbench results. But this code still 
uses ogl_2 and d3d_9 so it can be possible that the new versions of 
these API have a better alternative.


PS: I will once again look into java2d pipelines for tile constants (32) 
to see if other parts should be updated (TexturePaint ?)...
I also need help on testing such patches on many hw platforms to detect 
regressions (j2dBench, MapBench...)


I guess we can run these tests on at least supported configurations.

--
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up GensrcX11Wrappers

[Phil Race]

It isn't "unlikely" .. it is just "relatively rare".

-phil.

On 03/05/2018 04:00 PM, Magnus Ihse Bursie wrote:



On 2018-03-06 00:53, Phil Race wrote:
+ $(ECHO) needs to be updated for both 32 and 64 bit platforms. You 
have now needs -> need.
Fixed typo. Thanks! (I really hate how I suck at those English plural 
s'es :-&)
Could we make this easier by trying to generate the 32 bit native 
binary as well if running on 64 bits ? Looks like this was not 
normally done on Linux but if you have 32 bit compiler + library 
support it should work. Or do you consider it easy enough to just 
kick off a 32 bit build to get the same ?
Yes, I consider that easy enough, given how unlikely it is that this 
needs ever be done.


/Magnus


-phil.

On 03/05/2018 03:30 PM, Magnus Ihse Bursie wrote:


On 2018-03-05 23:38, Phil Race wrote:
>I'm not sure what role the "verification" step we had before ever 
played.
>For all the years we've been "verifying" this, we've detected no 
differences.


I think this is useful in the event that you make some changes and
regenerate the 64 bit sizes but not 32 bit.
That's a good point. I should add a warning message when 
regenerating the checked-in data files that you need to regenerate 
the files on both 32 and 64 bit platforms.


For example this old bug similarly reported a breakage on Solaris ..
https://bugs.openjdk.java.net/browse/JDK-6804680

... back in the day when we only had that checked in and the ones 
used for Linux
were being generated on the fly. My reading of the history here is 
sizes.32 and sizes.64
were added to support cross-compilation, and the verification step 
meant that  all

architectures would get checked in some build or other.


I'd rather say that it was at this time that we stopped run-time 
generation of the X11 size data. The "verification" step was there 
more like a comfort thing for the build team, since we was too 
conservative.



The clean up of removing the solaris specific seems like it could 
have been
done a long time ago .. I am not sure why was ever only this one 
case there.

I'd have to dig back a very long way.

I do agree we do not need to support 32 + 64 bit concurrently, that 
went

away when 64 bit solaris overlay on 32 bit was dropped.


Thank you.

Updated webrev with warning message about updating for all platforms:

http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.03 



(Only UpdateX11Wrappers.gmk has changed)

/Magnus



-phil.

On 03/02/2018 07:23 AM, Erik Joelsson wrote:
Adding 2d-dev in the hopes of getting some input from component 
team. Seems like they should be aware of us removing the support 
for multiple data models.


Looks like you left a debug message at line 40 in 
GensrcX11Wrappers.gmk.


/Erik

On 2018-03-02 03:00, Magnus Ihse Bursie wrote:

On 2018-03-02 00:02, Erik Joelsson wrote:

Hello,

In xlibtypes.txt comment, should it be sizes-64.txt?


Yes, good catch.



Generating both 32 and 64 seems a bit outdated at this point. 
Surely this is a remnant of bundling 64 and 32 bit together on 
Solaris in the past? Perhaps someone in 2d can answer this? 
Would be nice to be able to clean up that part as well if possible.
Yes, you are right. We should clean up that as well. I was just 
too conservative. I've now actually checked what happens when you 
generate both 32 and 64 bit versions, and the result is that 
instead of code like:

public static int getSize() { return 96; }
we get code like this:
public static int getSize() { return ((XlibWrapper.dataModel 
== 32)?(80):(96)); }


Since we do no longer support multiple data models for the same 
build, this is just unnecessary. In fact, that leads to an even 
better cleanup, since we will always need just a single input file.


I also wrapped the tool calls in ExecuteWithLog.

Updated webrev:
http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 



/Magnus

Re: [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up GensrcX11Wrappers

[Magnus Ihse Bursie]

On 2018-03-06 00:53, Phil Race wrote:
+ $(ECHO) needs to be updated for both 32 and 64 bit platforms. You 
have now needs -> need.
Fixed typo. Thanks! (I really hate how I suck at those English plural 
s'es :-&)
Could we make this easier by trying to generate the 32 bit native 
binary as well if running on 64 bits ? Looks like this was not 
normally done on Linux but if you have 32 bit compiler + library 
support it should work. Or do you consider it easy enough to just kick 
off a 32 bit build to get the same ?
Yes, I consider that easy enough, given how unlikely it is that this 
needs ever be done.


/Magnus


-phil.

On 03/05/2018 03:30 PM, Magnus Ihse Bursie wrote:


On 2018-03-05 23:38, Phil Race wrote:
>I'm not sure what role the "verification" step we had before ever 
played.
>For all the years we've been "verifying" this, we've detected no 
differences.


I think this is useful in the event that you make some changes and
regenerate the 64 bit sizes but not 32 bit.
That's a good point. I should add a warning message when regenerating 
the checked-in data files that you need to regenerate the files on 
both 32 and 64 bit platforms.


For example this old bug similarly reported a breakage on Solaris ..
https://bugs.openjdk.java.net/browse/JDK-6804680

... back in the day when we only had that checked in and the ones 
used for Linux
were being generated on the fly. My reading of the history here is 
sizes.32 and sizes.64
were added to support cross-compilation, and the verification step 
meant that  all

architectures would get checked in some build or other.


I'd rather say that it was at this time that we stopped run-time 
generation of the X11 size data. The "verification" step was there 
more like a comfort thing for the build team, since we was too 
conservative.



The clean up of removing the solaris specific seems like it could 
have been
done a long time ago .. I am not sure why was ever only this one 
case there.

I'd have to dig back a very long way.

I do agree we do not need to support 32 + 64 bit concurrently, that 
went

away when 64 bit solaris overlay on 32 bit was dropped.


Thank you.

Updated webrev with warning message about updating for all platforms:

http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.03 



(Only UpdateX11Wrappers.gmk has changed)

/Magnus



-phil.

On 03/02/2018 07:23 AM, Erik Joelsson wrote:
Adding 2d-dev in the hopes of getting some input from component 
team. Seems like they should be aware of us removing the support 
for multiple data models.


Looks like you left a debug message at line 40 in 
GensrcX11Wrappers.gmk.


/Erik

On 2018-03-02 03:00, Magnus Ihse Bursie wrote:

On 2018-03-02 00:02, Erik Joelsson wrote:

Hello,

In xlibtypes.txt comment, should it be sizes-64.txt?


Yes, good catch.



Generating both 32 and 64 seems a bit outdated at this point. 
Surely this is a remnant of bundling 64 and 32 bit together on 
Solaris in the past? Perhaps someone in 2d can answer this? Would 
be nice to be able to clean up that part as well if possible.
Yes, you are right. We should clean up that as well. I was just 
too conservative. I've now actually checked what happens when you 
generate both 32 and 64 bit versions, and the result is that 
instead of code like:

    public static int getSize() { return 96; }
we get code like this:
    public static int getSize() { return ((XlibWrapper.dataModel 
== 32)?(80):(96)); }


Since we do no longer support multiple data models for the same 
build, this is just unnecessary. In fact, that leads to an even 
better cleanup, since we will always need just a single input file.


I also wrapped the tool calls in ExecuteWithLog.

Updated webrev:
http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 



/Magnus

Re: [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up GensrcX11Wrappers

[Phil Race]

+ $(ECHO) needs to be updated for both 32 and 64 bit platforms. You have 
now needs -> need. Could we make this easier by trying to generate the 
32 bit native binary as well if running on 64 bits ? Looks like this was 
not normally done on Linux but if you have 32 bit compiler + library 
support it should work. Or do you consider it easy enough to just kick 
off a 32 bit build to get the same ? -phil.



On 03/05/2018 03:30 PM, Magnus Ihse Bursie wrote:


On 2018-03-05 23:38, Phil Race wrote:
>I'm not sure what role the "verification" step we had before ever 
played.
>For all the years we've been "verifying" this, we've detected no 
differences.


I think this is useful in the event that you make some changes and
regenerate the 64 bit sizes but not 32 bit.
That's a good point. I should add a warning message when regenerating 
the checked-in data files that you need to regenerate the files on 
both 32 and 64 bit platforms.


For example this old bug similarly reported a breakage on Solaris ..
https://bugs.openjdk.java.net/browse/JDK-6804680

... back in the day when we only had that checked in and the ones 
used for Linux
were being generated on the fly. My reading of the history here is 
sizes.32 and sizes.64
were added to support cross-compilation, and the verification step 
meant that  all

architectures would get checked in some build or other.


I'd rather say that it was at this time that we stopped run-time 
generation of the X11 size data. The "verification" step was there 
more like a comfort thing for the build team, since we was too 
conservative.



The clean up of removing the solaris specific seems like it could 
have been
done a long time ago .. I am not sure why was ever only this one case 
there.

I'd have to dig back a very long way.

I do agree we do not need to support 32 + 64 bit concurrently, that went
away when 64 bit solaris overlay on 32 bit was dropped.


Thank you.

Updated webrev with warning message about updating for all platforms:

http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.03 



(Only UpdateX11Wrappers.gmk has changed)

/Magnus



-phil.

On 03/02/2018 07:23 AM, Erik Joelsson wrote:
Adding 2d-dev in the hopes of getting some input from component 
team. Seems like they should be aware of us removing the support for 
multiple data models.


Looks like you left a debug message at line 40 in 
GensrcX11Wrappers.gmk.


/Erik

On 2018-03-02 03:00, Magnus Ihse Bursie wrote:

On 2018-03-02 00:02, Erik Joelsson wrote:

Hello,

In xlibtypes.txt comment, should it be sizes-64.txt?


Yes, good catch.



Generating both 32 and 64 seems a bit outdated at this point. 
Surely this is a remnant of bundling 64 and 32 bit together on 
Solaris in the past? Perhaps someone in 2d can answer this? Would 
be nice to be able to clean up that part as well if possible.
Yes, you are right. We should clean up that as well. I was just too 
conservative. I've now actually checked what happens when you 
generate both 32 and 64 bit versions, and the result is that 
instead of code like:

public static int getSize() { return 96; }
we get code like this:
public static int getSize() { return ((XlibWrapper.dataModel == 
32)?(80):(96)); }


Since we do no longer support multiple data models for the same 
build, this is just unnecessary. In fact, that leads to an even 
better cleanup, since we will always need just a single input file.


I also wrapped the tool calls in ExecuteWithLog.

Updated webrev:
http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 



/Magnus

Re: [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up GensrcX11Wrappers

[Magnus Ihse Bursie]

On 2018-03-05 23:38, Phil Race wrote:
>I'm not sure what role the "verification" step we had before ever 
played.
>For all the years we've been "verifying" this, we've detected no 
differences.


I think this is useful in the event that you make some changes and
regenerate the 64 bit sizes but not 32 bit.
That's a good point. I should add a warning message when regenerating 
the checked-in data files that you need to regenerate the files on both 
32 and 64 bit platforms.


For example this old bug similarly reported a breakage on Solaris ..
https://bugs.openjdk.java.net/browse/JDK-6804680

... back in the day when we only had that checked in and the ones used 
for Linux
were being generated on the fly. My reading of the history here is 
sizes.32 and sizes.64
were added to support cross-compilation, and the verification step 
meant that  all

architectures would get checked in some build or other.


I'd rather say that it was at this time that we stopped run-time 
generation of the X11 size data. The "verification" step was there more 
like a comfort thing for the build team, since we was too conservative.



The clean up of removing the solaris specific seems like it could have 
been
done a long time ago .. I am not sure why was ever only this one case 
there.

I'd have to dig back a very long way.

I do agree we do not need to support 32 + 64 bit concurrently, that went
away when 64 bit solaris overlay on 32 bit was dropped.


Thank you.

Updated webrev with warning message about updating for all platforms:

http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.03

(Only UpdateX11Wrappers.gmk has changed)

/Magnus



-phil.

On 03/02/2018 07:23 AM, Erik Joelsson wrote:
Adding 2d-dev in the hopes of getting some input from component team. 
Seems like they should be aware of us removing the support for 
multiple data models.


Looks like you left a debug message at line 40 in GensrcX11Wrappers.gmk.

/Erik

On 2018-03-02 03:00, Magnus Ihse Bursie wrote:

On 2018-03-02 00:02, Erik Joelsson wrote:

Hello,

In xlibtypes.txt comment, should it be sizes-64.txt?


Yes, good catch.



Generating both 32 and 64 seems a bit outdated at this point. 
Surely this is a remnant of bundling 64 and 32 bit together on 
Solaris in the past? Perhaps someone in 2d can answer this? Would 
be nice to be able to clean up that part as well if possible.
Yes, you are right. We should clean up that as well. I was just too 
conservative. I've now actually checked what happens when you 
generate both 32 and 64 bit versions, and the result is that instead 
of code like:

    public static int getSize() { return 96; }
we get code like this:
    public static int getSize() { return ((XlibWrapper.dataModel == 
32)?(80):(96)); }


Since we do no longer support multiple data models for the same 
build, this is just unnecessary. In fact, that leads to an even 
better cleanup, since we will always need just a single input file.


I also wrapped the tool calls in ExecuteWithLog.

Updated webrev:
http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 



/Magnus

Re: [OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up GensrcX11Wrappers

[Phil Race]

>I'm not sure what role the "verification" step we had before ever played.
>For all the years we've been "verifying" this, we've detected no 
differences.


I think this is useful in the event that you make some changes and
regenerate the 64 bit sizes but not 32 bit.

For example this old bug similarly reported a breakage on Solaris ..
https://bugs.openjdk.java.net/browse/JDK-6804680

... back in the day when we only had that checked in and the ones used 
for Linux
were being generated on the fly. My reading of the history here is 
sizes.32 and sizes.64
were added to support cross-compilation, and the verification step meant 
that  all

architectures would get checked in some build or other.

We care less about 32 bit now .. and even the cross-compilation .. so  
arguably
we could go back to always generating the files, as was the case for 
Linux before

https://bugs.openjdk.java.net/browse/JDK-8004151

But if we say we still want to keep around the possibility of 32 bit 
support AND

cross-compilation, then the verification step still seems useful.

If we say we care only about 32 bit or do not care about cross 
compilation, then

why not get rid of the checked in file and calculate these every build ?

The clean up of removing the solaris specific seems like it could have been
done a long time ago .. I am not sure why was ever only this one case there.
I'd have to dig back a very long way.

I do agree we do not need to support 32 + 64 bit concurrently, that went
away when 64 bit solaris overlay on 32 bit was dropped.

-phil.

On 03/02/2018 07:23 AM, Erik Joelsson wrote:
Adding 2d-dev in the hopes of getting some input from component team. 
Seems like they should be aware of us removing the support for 
multiple data models.


Looks like you left a debug message at line 40 in GensrcX11Wrappers.gmk.

/Erik

On 2018-03-02 03:00, Magnus Ihse Bursie wrote:

On 2018-03-02 00:02, Erik Joelsson wrote:

Hello,

In xlibtypes.txt comment, should it be sizes-64.txt?


Yes, good catch.



Generating both 32 and 64 seems a bit outdated at this point. Surely 
this is a remnant of bundling 64 and 32 bit together on Solaris in 
the past? Perhaps someone in 2d can answer this? Would be nice to be 
able to clean up that part as well if possible.
Yes, you are right. We should clean up that as well. I was just too 
conservative. I've now actually checked what happens when you 
generate both 32 and 64 bit versions, and the result is that instead 
of code like:

public static int getSize() { return 96; }
we get code like this:
public static int getSize() { return ((XlibWrapper.dataModel == 
32)?(80):(96)); }


Since we do no longer support multiple data models for the same 
build, this is just unnecessary. In fact, that leads to an even 
better cleanup, since we will always need just a single input file.


I also wrapped the tool calls in ExecuteWithLog.

Updated webrev:
http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 



/Magnus

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

[Laurent Bourgès]

Phil,

As promised, I made Marlin 0.9.1 benchmarks on windows & linux to compare
d3d, opengl & xrender backends on the same machine: I5 + nvidia 1070.
(I will test on mac OS X soon, if needed)

First Marlin 0.9.1 patch works well: no crash or bug with larger tiles
128x64 even if d3d / opengl uses internally 32x32 texture caches.
Moreover xrender pipeline is the fastest compared to D3D (40% slower) or
opengl (>250% slower) !

I will share later detailed results (plots) but raw data files are
available (see linux & win files):
https://github.com/bourgesl/bourgesl.github.io/commit/84133d54692affd1d96938a88ac4a041ec0f5e36


As previously mentioned, I increased the RenderQueue buffer (see patchs at
the end) to 4M (instead of 32K) and d3d & opengl get boosted.

Finally, I increased the cached tile sizes in OGLVertexCache.h and opengl
performance achieved xrender performance on linux:

--- /tmp/meld-tmpdLFq6S
+++
/home/graphics-rasterizer/jdk/client/src/java.desktop/share/native/common/java2d/opengl/OGLVertexCache.h
@@ -38,13 +38,13 @@
  * Constants that control the size of the texture tile cache used for
  * mask operations.
  */
-#define OGLVC_MASK_CACHE_TILE_WIDTH   32
-#define OGLVC_MASK_CACHE_TILE_HEIGHT  32
+#define OGLVC_MASK_CACHE_TILE_WIDTH   128   /* 32 */
+#define OGLVC_MASK_CACHE_TILE_HEIGHT  64/* 32 */
 #define OGLVC_MASK_CACHE_TILE_SIZE \
(OGLVC_MASK_CACHE_TILE_WIDTH * OGLVC_MASK_CACHE_TILE_HEIGHT)

-#define OGLVC_MASK_CACHE_WIDTH_IN_TILES   8
-#define OGLVC_MASK_CACHE_HEIGHT_IN_TILES  4
+#define OGLVC_MASK_CACHE_WIDTH_IN_TILES   16
+#define OGLVC_MASK_CACHE_HEIGHT_IN_TILES  8

 #define OGLVC_MASK_CACHE_WIDTH_IN_TEXELS \
(OGLVC_MASK_CACHE_TILE_WIDTH * OGLVC_MASK_CACHE_WIDTH_IN_TILES)


Thanks to Clemens, that explained me its xrender new approach and it
convinced me to tune java2d pipelines.

In conclusion, using larger tiles in Marlin 0.9.1 will allow large gains
either in d3d & opengl pipelines so I plan to propose these new fixes for
jdk11 soon.

News:
> - I modified opengl queue buffer capacity recently and got 30% better
> performance (mapbench) on linux. That could be worth for macOS: will create
> another jbs bug
> - I will work on upgrading MarlinFX to 0.9.1 soon to provide you a patch
> for openjfx 11.
>
> Who can review such patches & help me on improving java2d pipelines
> (discussion, skills) ?
>

Soory to insist but who could advice me and give me explanations on the
RenderQueue & d3d / opengl backends.

I read JBS for RenderQueue buffering as I have several questions
(asynchronous queue ?)
How to auto-tune such buffer capacity ?
It seems tricky as too small or too large buffers impacts performance as it
depends on the GPU speed (drain the buffer).
Is there any design document ?

PS: I will once again look into java2d pipelines for tile constants (32) to
see if other parts should be updated (TexturePaint ?)...
I also need help on testing such patches on many hw platforms to detect
regressions (j2dBench, MapBench...)

Cheers,
Laurent


--- /tmp/meld-tmpFaCMrF
+++
/home/graphics-rasterizer/jdk/client/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights
reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -25,9 +25,12 @@

 package sun.java2d.pipe;

+import java.security.AccessController;
 import java.util.HashSet;
 import java.util.Set;
+
 import sun.awt.SunToolkit;
+import sun.security.action.GetPropertyAction;

 /**
  * The RenderQueue class encapsulates a RenderBuffer on which rendering
@@ -72,20 +75,34 @@
 public abstract class RenderQueue {

 /** The size of the underlying buffer, in bytes. */
-private static final int BUFFER_SIZE = 32000;
+private static final int BUFFER_SIZE;
+
+static {
+BUFFER_SIZE = align(getInteger("sun.java2d.opengl.bufferSize",
4*1024 * 1024, 32 * 1024, 64 * 1024 * 1024), 1024);
+System.out.println("RenderQueue: sun.java2d.opengl.bufferSize =
"+BUFFER_SIZE);
+}

 /** The underlying buffer for this queue. */
-protected RenderBuffer buf;
+protected final RenderBuffer buf;

 /**
  * A Set containing hard references to Objects that must stay alive
until
  * the queue has been completely flushed.
  */
-protected Set refSet;
+protected final Set refSet;

 protected RenderQueue() {
-refSet = new HashSet<>();
+refSet = new HashSet(64); // large enough (LBO) ?
 buf = RenderBuffer.allocate(BUFFER_SIZE);
+}
+
+protected final void clear() {
+// reset the buffer position
+buf.clear();
+// clear the set of references, since we no longer need them
+refSet.clear();
 }

 /**
@@ -220,4 +237,35 @@
 buf.position(position);

Re: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS

[Bill York]

Alexey,

Thanks for the link. I have downloaded it and am trying it out now.

Bill

On 1/26/18, 5:53 AM, "Alexey Ushakov"  wrote:

Hello Bill,

You can try our production bits 
(https://bintray.com/jetbrains/intellij-jdk/download_file?file_path=jbsdk8u152b1136.5_osx_x64.tar.gz)

Best Regards,
Alexey 

> On 26 Jan 2018, at 01:52, Bill York  wrote:
> 
> Thanks for the update. We have numerous JDK8 users experiencing this 
crash.
> 
> Is JDK11 the only possible resolution?
> 
> Does anyone know of a work-around?
> 
> Thanks again,
> 
> Bill
> 
> 
> On 1/25/18, 5:48 PM, "Sergey Bylokhov"  wrote:
> 
>FYI: Review for those fix was not completed:
>http://mail.openjdk.java.net/pipermail/2d-dev/2015-December/006130.html
> 
>On 25/01/2018 13:31, Bill York wrote:
>> Could someone let me know if there are plans to fix this bug?
>> 
>> 1. In the OpenJDK code base?
>> 2. In the Oracle JDK?
> 
>The next release where it can be fixed is jdk11.
>Maybe Alexey can provide some additional information?
> 
>-- 
>Best regards, Sergey.
> 
>