On 2/10/15 7:52 AM, Sergey Bylokhov wrote:
You can run this test on jdk 8u31 and 8u40 to see a difference:
http://cr.openjdk.java.net/~serb/8029253/webrev.04/test/java/awt/image/DrawImage/UnmanagedDrawImagePerformance.java.html
And the test from this bug report:
https://bugs.openjdk.java.net/browse/JDK-8017247
After looking at those tests, they are definitely not related to the
issue I'm seeing here. Although the TurboVNC Viewer (my application)
does use bilinear interpolation if desktop scaling is enabled, that is
not the "common" usage case. Normally, it's just going to be drawing a
BufferedImage with no interpolation, so that at least clarifies that I
shouldn't be expecting any different behavior with Java 9. The question
now becomes: how to optimally take advantage of the OpenGL pipeline.
As you pointed out (and I agree, based on my research) reducing the
software-to-surface blits is key, although I don't have a firm grasp on
how to do that. My code is basically just doing the following:
public void paintComponent(Graphics g) {
Graphics2D g2 = (Graphics2D) g;
if (scaling enabled) {
g2.setRenderingHint(RenderingHints.KEY_INTERPOLATION,
RenderingHints.VALUE_INTERPOLATION_BILINEAR);
g2.drawImage(im.getImage(), 0, 0, scaledWidth, scaledHeight, null);
} else {
g2.drawImage(im.getImage(), 0, 0, null);
}
g2.dispose();
}
public void updateWindow() {
Rect r = damage;
if (!r.isEmpty()) {
if (scaling enabled) {
blah blah blah (adjust coordinates, mainly)
paintImmediately(x, y, width, height);
} else {
paintImmediately(x, y, width, height);
}
damage.clear();
}
}
As VNC rectangles from the server are decoded, the "damage" rectangle
gets updated to reflect the extent of the "damaged" pixels, and that
extent is passed into paintImmediately(). In examining the OpenJDK
source, however, it appears that glDrawPixels() is always called with
the full extent of the BufferedImage, regardless of whether only a small
portion of that image has actually changed. If there is something else
I can do to help debug this, please let me know. I have a working JDK
build. I fully admit that I may be doing something wrong or
suboptimally, but bear in mind that I've spent probably over 100 hours
on this, so it's not as if I'm a naive n00b here. If there's something
I'm missing, then trust me that it isn't obvious!
Can you share standalone jar file of this workload?
Here is everything you need to reproduce the issue:
http://www.turbovnc.org/turbovnc_mac_performance_stuff.tar.gz
Untar, then do
cd turbovnc_mac_performance_stuff
java -server -d64 -Dsun.java2d.trace=count -cp VncViewer.jar
com.turbovnc.vncviewer.ImageDrawTest
(let it run for 20 seconds or so, then CTRL-C it.)
java -server -d64 -jar VncViewer.jar -bench compilation-16.rfb -benchiter 3
-benchwarmup 2
(let it run to completion.)
Results from Java 6u51 on my Mac Mini (2009 vintage, 2 GHz Intel Core
Duo, nVidia GeForce 9400):
ImageDrawTest: ~100 Mpixels/sec
(all calls are to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa,
IntArgbPre))
compilation-16: Average 1.392763 s (Decode = 0.198173 s, Blit =
1.005974 s)
Results from Java 8u31 on my Mac Mini:
ImageDrawTest: ~70 Mpixels/sec
(Calls are split between
sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL Surface
(render-to-texture)", AnyAlpha, "OpenGL Surface") and
sun.java2d.opengl.OGLSwToSurfaceBlit::Blit(IntArgbPre, AnyAlpha,
"OpenGL Surface"))
compilation-16: Average 6.216550 s (Decode = 0.194989 s, Blit =
5.534781 s)
Results from Java 8u31 on my Mac Mini without alpha-enabled image
(-Dturbovnc.forcealpha=false):
ImageDrawTest: ~18 Mpixels/sec
(Calls are split between:
sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL Surface
(render-to-texture)", AnyAlpha, "OpenGL Surface") and
sun.java2d.opengl.OGLSwToSurfaceBlit::Blit(IntRgb, AnyAlpha,
"OpenGL Surface"))
compilation-16: Average 27.153480 s (Decode = 0.200333 s, Blit =
26.523137 s)
So, as you can see, using an alpha-enabled image improved the
performance under Java 7/8 by about 4x, both when drawing large images
(ImageDrawTest) and when doing smaller image updates (compilation-16.)
However, the blitting performance under Java 7/8 for small image
workloads is still about 5x slower than it was under Java 6. Results
from a different machine:
Results from Java 6u51 on my Macbook Pro (2011 vintage, 2.4 GHz Intel
Core i5, Intel HD Graphics 3000):
ImageDrawTest: ~100 Mpixels/sec
(all calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgbPre))
compilation-16: Average 0.592772 s (Decode = 0.113879 s, Blit =
0.351596 s)
Results from Java 8u31 on my Macbook Pro:
ImageDrawTest: ~66 Mpixels/sec
(Calls split between
sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL Surface
(render-to-texture)", AnyAlpha, "OpenGL Surface") and
sun.java2d.opengl.OGLSwToSurfaceBlit::Blit(IntArgbPre, AnyAlpha,
"OpenGL Surface"))
compilation-16: Average 6.806324 s (Decode = 0.188252 s, Blit =
6.457852 s)
Results from Java 8u31 on my Macbook Pro without alpha-enabled image
(-Dturbovnc.forcealpha=false):
ImageDrawTest: ~50 Mpixels/sec
(Calls split between
sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL Surface
(render-to-texture)", AnyAlpha, "OpenGL Surface") and
sun.java2d.opengl.OGLSwToSurfaceBlit::Blit(IntRgb, AnyAlpha,
"OpenGL Surface"))
compilation-16: Average 10.272508 s (Decode = 0.147805 s, Blit =
9.955666 s)
Using an ARGB_PRE BufferedImage didn't help out nearly as much on this
machine, and whereas the large image performance looks similar to that
of the Mac Mini, the small image blitting performance still suffers by
nearly a factor of 20 (although it is improved-- before the use of
ARGB_PRE images, it was about a factor of 30 slower.)
The architecture of this solution makes the use of VolatileImages
impractical-- basically, I have to decode the VNC rectangles in real
time as they arrive, so if the VolatileImage were to go away, I would
have no way of rebuilding it.
