Any news here Sergey?
> Am 17.02.2015 um 15:01 schrieb Sergey Bylokhov <sergey.bylok...@oracle.com>: > > Hello, > Thanks for the provided info! I am able to reproduce this bug even on > windows: gdi vs ogl. I will take a look at it. > > On 12.02.2015 8:28, DRC wrote: >> 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. > > > -- > Best regards, Sergey. >
