Hello, > On 2/9/15 10:32 AM, Sergey Bylokhov wrote: > OK, but CreateCompatibleImage() always gives me TYPE_INT_RGB, which is> > not optimal when using OpenGL blitting. That's why I have to go to > the > trouble of detecting Java 1.7-1.8 on Mac and forcing the use of a > TYPE_INT_ARGB_PRE image in that case.
Probably you do not provide the third argument of this method? > (1) Why didn't the Quartz blitter from Apple's Java 1.6 ever make it > into Oracle Java? Was there a licensing issue with that code? I do not remember a details but it was a discussion about it, and as a result Quartz pipeline was not ported to the openjdk. > > (2) What benchmarks are you using to measure Java 2D performance? > That > is, what is the data that is driving the design decision to use only > OpenGL blitting on Mac? On other platforms, there are multiple > blitter options. There are a few benchmars: Most useful is J2DBench, which located in the openjdk repo: http://hg.openjdk.java.net/jdk9/client/jdk/file/cf29d39bf0de/src/demo/share/java2d/J2DBench Report example: http://cr.openjdk.java.net/~serb/8029253/perf.04/osx-retina-intel/results.txt > > (3) Is Java 9 supposed to make this faster in any way? Your other > message > (http://mail.openjdk.java.net/pipermail/2d-dev/2014-October/004870.html) > > indicated that there was some change introduced in the Java 9 > pre-releases that might affect this, but after testing the pre-release > > builds, I can't make them perform any differently than Java 7 or 8. Same fixes were pushed to 8u40. All of them related to the BufferedImage2surface scaleblit. Example report http://cr.openjdk.java.net/~serb/8059942/ogl_nvidia_win_fix14/results_ogl.txt > > As far as rewriting the Java 2D blitter, that is more monumental of a > > task than I have time for. I'm mainly trying to figure out: > > -- why the Quartz blitter went away > -- whether there's any chance of bringing it back I suppose this is impossible in this moment. > -- whether I'm doing the right thing to achieve peak performance under the > OpenGL blitter > > The OpenGL blitter is slower in two key ways: > (a) even when using ARGB_PRE images, the raw pixel throughput is still > > slower by about 1/3 relative to the Quartz blitter, and > (b) the OpenGL blitter seems to want to redraw the entire image when I > > repaint, even if only a small portion has changed. The Quartz > blitter, on the other hand, seems smart enough to only update the changed > portion, which is much faster when dealing with a lot of small updates to the > back buffer. All this should be measured first, because most of the time ogl texture2texture blit is quite fast. And problems became obvious when some BufferedImages is not cached in the texture or incorrect/not best image formats are used. > All of this Java 2D stuff is kind of a black box, and the only way I > was > able to figure out what Java 2D was doing behind the scenes was to > build > the OpenJDK source and insert print statements into it. But it still > > seems that the back-end behavior can be somewhat different depending > on which Java 2D blitter is used. There are some options which can help: # export J2D_TRACE_LEVEL=4 # java -Dsun.java2d.opengl=True -Dsun.java2d.trace=log YourApp http://docs.oracle.com/javase/7/docs/technotes/guides/2d/flags.html http://www.oracle.com/technetwork/java/javase/java2d-142140.html Using these options you can check what blits are used in your program, and then you can measure their performance using J2DBench using different pipelines/platforms/options.
