From Phil.Race at Sun.COM Wed Jul 2 19:00:02 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 02 Jul 2008 12:00:02 -0700 Subject: [OpenJDK 2D-Dev] CFV: Doug Felt to Membership in the 2D group In-Reply-To: <486142B8.9010705@sun.com> References: <486142B8.9010705@sun.com> Message-ID: <486BD032.1030507@sun.com> The CFV for Doug Felt's membership has now closed, and the results have been tallied. There were 9 "Yes" votes and 0 "no" votes. This is sufficient to approve the proposal for Doug Felt to become a Member of the 2D group. Welcome Doug. -phil. Phil Race wrote: > > I hereby nominate Doug Felt as a member of the OpenJDK 2D group. > > Doug has made significant contributions to the Java 2D text APIs > and their implementation starting in 1997 and in every release from JDK 1.2 > up to and including JDK 6. As part of the Taligent (later IBM) team > he helped to create the advanced text APIs including those in the > java.awt.font package, and as part of the ICU team directly handled > integrating bidi text and ICU opentype layout in JDK. > Doug has also been a JavaOne speaker on the JDK's text APIs > and implementation. > > Please cast your vote by replying publicly to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may indicate the reason for your vote, if you wish, on > subsequent lines. This is optional and not required. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > Only current members of the 2D Group are eligible to vote. > > Votes are due by midnight UTC Sun 29th June 2008 after which time the > votes will be tallied and reported to this list . > > -Phil. From roman.kennke at aicas.com Thu Jul 3 21:18:08 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Thu, 03 Jul 2008 23:18:08 +0200 Subject: [OpenJDK 2D-Dev] Where is TransformBlit.Transform()? Message-ID: <1215119888.24218.8.camel@moonlight> For some reason I can't seem to find any native implementation for sun.java2d.loops.TransformBlit.Transform() . Has it been forgotten or is this simply never called? /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From Jim.A.Graham at Sun.COM Tue Jul 8 17:51:58 2008 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Tue, 08 Jul 2008 10:51:58 -0700 Subject: [OpenJDK 2D-Dev] Where is TransformBlit.Transform()? In-Reply-To: <1215119888.24218.8.camel@moonlight> References: <1215119888.24218.8.camel@moonlight> Message-ID: <0K3P009KS899S6F0@fe-sfbay-10.sun.com> We don't use it for our software loops - we use TransformHelper instead. I think the only 2 pipelines that use this type of loop are the OGL and D3D pipelines and they probably only create subclasses that override the method and vector it into the RenderQueue so this native method may not have ever been created since it would never get called (it's not an error to declare an undefined native method as long as you never call it). It should probably be abstract for accuracy, but other than your wild goose chase it isn't hurting anything by being declared native... ...jim Roman Kennke wrote: > For some reason I can't seem to find any native implementation for > sun.java2d.loops.TransformBlit.Transform() . Has it been forgotten or is > this simply never called? > > /Roman > From roman.kennke at aicas.com Tue Jul 8 18:55:24 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 08 Jul 2008 20:55:24 +0200 Subject: [OpenJDK 2D-Dev] Where is TransformBlit.Transform()? In-Reply-To: <0K3P009KS899S6F0@fe-sfbay-10.sun.com> References: <1215119888.24218.8.camel@moonlight> <0K3P009KS899S6F0@fe-sfbay-10.sun.com> Message-ID: <1215543324.18370.5.camel@moonlight> Hey Jim, > We don't use it for our software loops - we use TransformHelper instead. > I think the only 2 pipelines that use this type of loop are the OGL > and D3D pipelines and they probably only create subclasses that override > the method and vector it into the RenderQueue so this native method may > not have ever been created since it would never get called (it's not an > error to declare an undefined native method as long as you never call it). Thanks for your reply. I agree, it is not exactly an error, I was only wondering if I was missing something. > It should probably be abstract for accuracy, but other than your wild > goose chase it isn't hurting anything by being declared native... Actually, it hurts me a little, because the way that my VM calls native methods is a little different and less dynamic than Hotspot does. We create native stubs for all native methods of an application that in turn call the JNI method, and then link everything together statically in one binary. The linker then complains if a native method is missing. A method that is declared native and doesn't have an impl does hurt me, if only a little (I simply add a dummy noop implementation to fix it). Either way, it would be cleaner and safer to declare this method abstract. This is why we are coding Java and not Python, right? ;-) But we can just as well leave it like it is and not worry and hope that this method really isn't called. I was only wondering if I miss something. Cheers, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From linuxhippy at gmail.com Thu Jul 10 13:24:27 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 10 Jul 2008 15:24:27 +0200 Subject: [OpenJDK 2D-Dev] DrawHandler and clipping / 1x1 ovals Message-ID: <194f62550807100624y15a59784y205be472c07654df@mail.gmail.com> Hello, 1.) While tuning fillOval performance I noticed that the scanlines generated by DrawHandler don't respect clipping, I get scanlines even for the areas which are clipped away later by X. Is DrawHandler capable of clipping, and if so how can this be done? 2.) I am using DoPath for ovals too, because XRender only supports rectangles, and I noticed that very small ovals differ when rendered to a BufferedImage, compared result I get when using the X11 pipeline. Java_sun_java2d_x11_X11Renderer_XFillOval has special case handling for very small shapes to be more accurat, however I don't know if the results generated by DrawHandler are "wrong" or the special-case handling. When filling an Oval with width/height=2, I get a rectangle with width=2/height=1 with BI and DrawHandler, but a 2x2 rect on X11. Well, I guess its not important at all, I just thought it could be worth telling. Thanks, Clemens From igor.nekrestyanov at sun.com Tue Jul 15 12:10:22 2008 From: igor.nekrestyanov at sun.com (igor.nekrestyanov at sun.com) Date: Tue, 15 Jul 2008 12:10:22 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6720240: IOB exception when getting font metrics of hershey font Message-ID: <20080715121037.9D9F6D13C@hg.openjdk.java.net> Changeset: c1e0755434eb Author: igor Date: 2008-07-15 16:04 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/c1e0755434eb 6720240: IOB exception when getting font metrics of hershey font Reviewed-by: bae, prr ! src/share/classes/sun/font/NullFontScaler.java From linuxhippy at gmail.com Tue Jul 15 22:28:46 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 16 Jul 2008 00:28:46 +0200 Subject: [OpenJDK 2D-Dev] Reporitory, Accalerating blits with EA Message-ID: <194f62550807151528j53b2da19ydbccb641dac5afc1@mail.gmail.com> Hi again, - The Xrender-pipeline now is almost able to run common swing applications, copyArea and some bugs are still waiting to be killed, but more or less it should work after. Its only the "hack" release where I tried all the stuff out and I plan to rewrite it starting next week or so, but it would be great if I could upload it to the OpenJDK repository. What should I do to get access to it? - My blit-functions currently are not called if composition with extra-alpha is requested, although I have registered my Blits with CompositeType.AnyAlpha. Are there further requirements to get this accalerated? - How does ExtraAlpha influence composition for operators other than SRC_OVER? For now I implement extra-alpha as a 1x1 A8 mask, however although the results are consistent when SRC_OVER is used, when SRC is used the image gets darker and darker the lower the EA value becomes with Xrender, but the RI seems to ignore the the extra-alpha value set. Thank you in advance, lg Clemens Blog: http://linuxhippy.blogspot.com/ From Christopher.Campbell at Sun.COM Tue Jul 15 23:00:04 2008 From: Christopher.Campbell at Sun.COM (Chris Campbell) Date: Tue, 15 Jul 2008 16:00:04 -0700 Subject: [OpenJDK 2D-Dev] Reporitory, Accalerating blits with EA In-Reply-To: <194f62550807151528j53b2da19ydbccb641dac5afc1@mail.gmail.com> References: <194f62550807151528j53b2da19ydbccb641dac5afc1@mail.gmail.com> Message-ID: Hi Clemens, On Jul 15, 2008, at 3:28 PM, Clemens Eisserer wrote: > Hi again, > > - The Xrender-pipeline now is almost able to run common swing > applications, copyArea and some bugs are still waiting to be killed, > but more or less it should work after. > Its only the "hack" release where I tried all the stuff out and I plan > to rewrite it starting next week or so, but it would be great if I > could upload it to the OpenJDK repository. > What should I do to get access to it? > There's an hg repository already set up for your Xrender project: http://hg.openjdk.java.net/xrender/xrender/ I'm not sure the process you need to follow to get commit access to it (maybe you could ask Mark Reinhold about that on a separate alias, like the discuss alias?). In theory that should be your sandbox (a child of the jdk7 master repository) as you work to stabilize your new pipeline. > - My blit-functions currently are not called if composition with > extra-alpha is requested, although I have registered my Blits with > CompositeType.AnyAlpha. Are there further requirements to get this > accalerated? > Do you know which Blit loop is being called in its place? (You can use -Dsun.java2d.trace=log to get an idea, or you can just step through the Blit.getFromCache() method.) I suspect there is another, more specific Blit loop that's already registered that is being found before the one you registered, but that's just a guess. > - How does ExtraAlpha influence composition for operators other than > SRC_OVER? > For now I implement extra-alpha as a 1x1 A8 mask, however although the > results are consistent when SRC_OVER is used, when SRC is used the > image gets darker and darker the lower the EA value becomes with > Xrender, but the RI seems to ignore the the extra-alpha value set. > "Extra alpha" has the same behavior for all AlphaComposite instances. In a nutshell, the extra alpha value gets logically multiplied with the source before the actual compositing operation. The AlphaComposite docs explain this process in great detail (look for the A[sub]ac factor): http://java.sun.com/javase/6/docs/api/java/awt/AlphaComposite.html Chris > > Thank you in advance, lg Clemens > > Blog: http://linuxhippy.blogspot.com/ From linuxhippy at gmail.com Wed Jul 16 14:17:27 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 16 Jul 2008 16:17:27 +0200 Subject: [OpenJDK 2D-Dev] Reporitory, Accalerating blits with EA In-Reply-To: References: <194f62550807151528j53b2da19ydbccb641dac5afc1@mail.gmail.com> Message-ID: <194f62550807160717k40743412j4b5c1e22b2fa2873@mail.gmail.com> Hi Chris, > I'm not sure the process you need to follow to get commit access to it > (maybe you could ask Mark Reinhold about that on a separate alias, like the > discuss alias?). Thanks for the hint, Mark sent me the registration invitation. > Do you know which Blit loop is being called in its place? (You can use > -Dsun.java2d.trace=log to get an idea, or you can just step through the > Blit.getFromCache() method.) I suspect there is another, more specific Blit > loop that's already registered that is being found before the one you > registered, but that's just a guess. Ah, that was a bit weird ;) With xorg-server-1.3 I hit a slow-path in the xserver, so I thought that would cause the same slowness in Java2D's FadeAnim. With xorg-server-1.5 my test was fast but FadeAnim was still slow, because it uses getSubImage() for the surfing duke. I changed the FadeAnim demo a bit to not use getSubImage() anymore and now it performs as expected, also the OGL/D3D pipelines should benefit from that change. Is there interest to include that small improvement? If not, no problem of course ;) > "Extra alpha" has the same behavior for all AlphaComposite instances. In a > nutshell, the extra alpha value gets logically multiplied with the source > before the actual compositing operation. The AlphaComposite docs explain > this process in great detail (look for the A[sub]ac factor): > http://java.sun.com/javase/6/docs/api/java/awt/AlphaComposite.html Thanks for the explanation. I guess the reason for the behaviour I see is a xserver-bug ... I am not really sure what to do about it till now. Owen Taylor described it as: > (Pixman of course, does fetch transparent, - it's just that a > transparent source gives you black for operator=Src and an opaque > target.) I paint the scanlines and lines to an alpha-mask which I use later for composition. Instead of transparent for the (1- extra-alpha) part I get black, thats why the result differs. Thanks, Clemens From dmitri.trembovetski at sun.com Fri Jul 18 17:56:29 2008 From: dmitri.trembovetski at sun.com (dmitri.trembovetski at sun.com) Date: Fri, 18 Jul 2008 17:56:29 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6725214: D3D: forward-port the new pipeline from 6u10 Message-ID: <20080718175641.AAAC8D393@hg.openjdk.java.net> Changeset: 3efc003bf097 Author: tdv Date: 2008-07-18 10:48 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3efc003bf097 6725214: D3D: forward-port the new pipeline from 6u10 Summary: Forward port of the new Direct3D 9 rendering pipeline from 6u10. Also includes fixes for 6690659 6689025 6658398 6596234. Reviewed-by: campbell, prr ! make/common/shared/Platform.gmk ! make/common/shared/Sanity.gmk ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/FILES_export_windows.gmk ! make/sun/awt/Makefile ! make/sun/awt/make.depend ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/font/FILES_c.gmk ! make/sun/font/Makefile ! make/sun/headless/mapfile-vers ! make/sun/jawt/make.depend ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/image/DataBuffer.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/share/classes/sun/awt/SubRegionShowable.java ! src/share/classes/sun/awt/image/SunVolatileImage.java ! src/share/classes/sun/awt/image/SunWritableRaster.java + src/share/classes/sun/awt/image/VSyncedBSManager.java ! src/share/classes/sun/awt/image/VolatileSurfaceManager.java ! src/share/classes/sun/font/StrikeCache.java + src/share/classes/sun/java2d/DestSurfaceProvider.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java + src/share/classes/sun/java2d/Surface.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/SurfaceDataProxy.java ! src/share/classes/sun/java2d/loops/BlitBg.java ! src/share/classes/sun/java2d/loops/GeneralRenderer.java ! src/share/classes/sun/java2d/opengl/OGLBufImgOps.java ! src/share/classes/sun/java2d/opengl/OGLContext.java ! src/share/classes/sun/java2d/opengl/OGLGraphicsConfig.java ! src/share/classes/sun/java2d/opengl/OGLPaints.java ! src/share/classes/sun/java2d/opengl/OGLRenderer.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/share/classes/sun/java2d/pipe/BufferedContext.java ! src/share/classes/sun/java2d/pipe/BufferedOpCodes.java ! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java ! src/share/classes/sun/java2d/pipe/DrawImage.java + src/share/classes/sun/java2d/pipe/ParallelogramPipe.java + src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java + src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventListener.java + src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java + src/share/classes/sun/java2d/pipe/hw/AccelGraphicsConfig.java + src/share/classes/sun/java2d/pipe/hw/AccelSurface.java + src/share/classes/sun/java2d/pipe/hw/AccelTypedVolatileImage.java + src/share/classes/sun/java2d/pipe/hw/BufferedContextProvider.java + src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java + src/share/classes/sun/java2d/pipe/hw/ExtendedBufferCapabilities.java ! src/share/native/sun/font/AccelGlyphCache.c ! src/share/native/sun/font/AccelGlyphCache.h ! src/share/native/sun/font/sunFont.c + src/share/native/sun/java2d/ShaderList.c + src/share/native/sun/java2d/ShaderList.h ! src/share/native/sun/java2d/Trace.h ! src/share/native/sun/java2d/loops/BlitBg.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h ! src/share/native/sun/java2d/opengl/OGLContext.c ! src/share/native/sun/java2d/opengl/OGLContext.h ! src/share/native/sun/java2d/opengl/OGLFuncs.h ! src/share/native/sun/java2d/opengl/OGLRenderQueue.c ! src/share/native/sun/java2d/opengl/OGLRenderQueue.h ! src/share/native/sun/java2d/opengl/OGLRenderer.c ! src/share/native/sun/java2d/opengl/OGLRenderer.h ! src/share/native/sun/java2d/opengl/OGLSurfaceData.c ! src/share/native/sun/java2d/opengl/OGLSurfaceData.h ! src/share/native/sun/java2d/pipe/BufferedMaskBlit.c ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/classes/sun/awt/motif/MComponentPeer.java + src/solaris/classes/sun/java2d/BackBufferCapsProvider.java ! src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java ! src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java ! src/solaris/classes/sun/java2d/opengl/GLXVolatileSurfaceManager.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/solaris/native/sun/java2d/opengl/GLXGraphicsConfig.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/windows/classes/sun/awt/Win32GraphicsConfig.java ! src/windows/classes/sun/awt/Win32GraphicsDevice.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java + src/windows/classes/sun/java2d/ScreenUpdateManager.java ! src/windows/classes/sun/java2d/WindowsSurfaceManagerFactory.java - src/windows/classes/sun/java2d/d3d/D3DBackBufferSurfaceData.java ! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java + src/windows/classes/sun/java2d/d3d/D3DBufImgOps.java ! src/windows/classes/sun/java2d/d3d/D3DContext.java ! src/windows/classes/sun/java2d/d3d/D3DDrawImage.java + src/windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java + src/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java + src/windows/classes/sun/java2d/d3d/D3DMaskBlit.java ! src/windows/classes/sun/java2d/d3d/D3DMaskFill.java + src/windows/classes/sun/java2d/d3d/D3DPaints.java + src/windows/classes/sun/java2d/d3d/D3DRenderQueue.java ! src/windows/classes/sun/java2d/d3d/D3DRenderer.java + src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java + src/windows/classes/sun/java2d/d3d/D3DSurfaceDataProxy.java ! src/windows/classes/sun/java2d/d3d/D3DTextRenderer.java + src/windows/classes/sun/java2d/d3d/D3DVolatileSurfaceManager.java ! src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java ! src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java ! src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java - src/windows/classes/sun/java2d/windows/DDBlitLoops.java - src/windows/classes/sun/java2d/windows/DDRenderer.java - src/windows/classes/sun/java2d/windows/DDScaleLoops.java ! src/windows/classes/sun/java2d/windows/GDIBlitLoops.java + src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java - src/windows/classes/sun/java2d/windows/Win32OffScreenSurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceDataProxy.java - src/windows/classes/sun/java2d/windows/WinBackBuffer.java - src/windows/classes/sun/java2d/windows/WinBackBufferSurfaceData.java - src/windows/classes/sun/java2d/windows/WinVolatileSurfaceManager.java ! src/windows/classes/sun/java2d/windows/WindowsFlags.java + src/windows/native/sun/java2d/d3d/D3DBadHardware.h ! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp + src/windows/native/sun/java2d/d3d/D3DBlitLoops.h + src/windows/native/sun/java2d/d3d/D3DBufImgOps.cpp + src/windows/native/sun/java2d/d3d/D3DBufImgOps.h ! src/windows/native/sun/java2d/d3d/D3DContext.cpp ! src/windows/native/sun/java2d/d3d/D3DContext.h + src/windows/native/sun/java2d/d3d/D3DGlyphCache.cpp + src/windows/native/sun/java2d/d3d/D3DGlyphCache.h + src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp + src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.h + src/windows/native/sun/java2d/d3d/D3DMaskBlit.cpp + src/windows/native/sun/java2d/d3d/D3DMaskBlit.h + src/windows/native/sun/java2d/d3d/D3DMaskCache.cpp + src/windows/native/sun/java2d/d3d/D3DMaskCache.h ! src/windows/native/sun/java2d/d3d/D3DMaskFill.cpp + src/windows/native/sun/java2d/d3d/D3DMaskFill.h + src/windows/native/sun/java2d/d3d/D3DPaints.cpp + src/windows/native/sun/java2d/d3d/D3DPaints.h + src/windows/native/sun/java2d/d3d/D3DPipeline.cpp + src/windows/native/sun/java2d/d3d/D3DPipeline.h + src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp + src/windows/native/sun/java2d/d3d/D3DPipelineManager.h + src/windows/native/sun/java2d/d3d/D3DRenderQueue.cpp + src/windows/native/sun/java2d/d3d/D3DRenderQueue.h ! src/windows/native/sun/java2d/d3d/D3DRenderer.cpp + src/windows/native/sun/java2d/d3d/D3DRenderer.h + src/windows/native/sun/java2d/d3d/D3DResourceManager.cpp + src/windows/native/sun/java2d/d3d/D3DResourceManager.h - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.cpp - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.h + src/windows/native/sun/java2d/d3d/D3DShaderGen.c + src/windows/native/sun/java2d/d3d/D3DShaders.h ! src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp ! src/windows/native/sun/java2d/d3d/D3DSurfaceData.h - src/windows/native/sun/java2d/d3d/D3DTestRaster.h ! src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp + src/windows/native/sun/java2d/d3d/D3DTextRenderer.h - src/windows/native/sun/java2d/d3d/D3DTextRenderer_md.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.h + src/windows/native/sun/java2d/d3d/D3DVertexCacher.cpp + src/windows/native/sun/java2d/d3d/D3DVertexCacher.h ! src/windows/native/sun/java2d/opengl/WGLGraphicsConfig.c ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.h - src/windows/native/sun/java2d/windows/DDBlitLoops.cpp - src/windows/native/sun/java2d/windows/DDRenderer.cpp ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp + src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp + src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.h - src/windows/native/sun/java2d/windows/RegistryKey.cpp - src/windows/native/sun/java2d/windows/RegistryKey.h - src/windows/native/sun/java2d/windows/Win32OffScreenSurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.h - src/windows/native/sun/java2d/windows/WinBackBufferSurfaceData.cpp ! src/windows/native/sun/java2d/windows/WindowsFlags.cpp ! src/windows/native/sun/java2d/windows/WindowsFlags.h - src/windows/native/sun/java2d/windows/ddrawObject.cpp - src/windows/native/sun/java2d/windows/ddrawObject.h - src/windows/native/sun/java2d/windows/ddrawUtils.cpp - src/windows/native/sun/java2d/windows/ddrawUtils.h - src/windows/native/sun/java2d/windows/dxCapabilities.cpp - src/windows/native/sun/java2d/windows/dxCapabilities.h - src/windows/native/sun/java2d/windows/dxInit.cpp - src/windows/native/sun/java2d/windows/dxInit.h ! src/windows/native/sun/windows/Devices.cpp ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_DrawingSurface.cpp ! src/windows/native/sun/windows/awt_DrawingSurface.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.h ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h ! src/windows/native/sun/windows/awtmsg.h + test/java/awt/FullScreen/BufferStrategyExceptionTest/BufferStrategyExceptionTest.java + test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java + test/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java + test/java/awt/FullScreen/SetFSWindow/FSFrame.java + test/java/awt/Multiscreen/DeviceIdentificationTest/DeviceIdentificationTest.java + test/java/awt/image/MemoryLeakTest/MemoryLeakTest.java + test/sun/java2d/DirectX/AccelPaintsTest/AccelPaintsTest.java + test/sun/java2d/DirectX/AcceleratedScaleTest/AcceleratedScaleTest.java + test/sun/java2d/DirectX/IAEforEmptyFrameTest/IAEforEmptyFrameTest.java + test/sun/java2d/DirectX/InfiniteValidationLoopTest/InfiniteValidationLoopTest.java + test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java + test/sun/java2d/DirectX/OverriddenInsetsTest/OverriddenInsetsTest.java + test/sun/java2d/DirectX/RenderingToCachedGraphicsTest/RenderingToCachedGraphicsTest.java + test/sun/java2d/DirectX/StrikeDisposalCrashTest/StrikeDisposalCrashTest.java + test/sun/java2d/DirectX/SwingOnScreenScrollingTest/SwingOnScreenScrollingTest.java + test/sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java + test/sun/java2d/GdiRendering/InsetClipping.java + test/sun/java2d/OpenGL/DrawBufImgOp.java + test/sun/java2d/SunGraphics2D/DrawImageBilinear.java + test/sun/java2d/SunGraphics2D/PolyVertTest.java + test/sun/java2d/SunGraphics2D/SimplePrimQuality.java + test/sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java + test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java + test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh + test/sun/java2d/pipe/MutableColorTest/MutableColorTest.java + test/sun/java2d/pipe/hw/RSLAPITest/RSLAPITest.java + test/sun/java2d/pipe/hw/VSyncedBufferStrategyTest/VSyncedBufferStrategyTest.java From linuxhippy at gmail.com Mon Jul 21 13:55:05 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 21 Jul 2008 15:55:05 +0200 Subject: [OpenJDK 2D-Dev] xrender-pipeline prototype/hack uploaded Message-ID: <194f62550807210655v77d56cbdl7e4fdcbfff3bc190@mail.gmail.com> Hello, This week I plan to start with a clean rewrite of the xrender-pipeline, to factor out the X11 and XRender specific parts from the common code base as far as possible and do things the right way. The current release is just a prototype/hack where I broke the existing source, many things are done in a very ugly or wrong way, and my goal would be to clean this mess up. Because of the limited time frame and my lack of prior experience with Java2D I decided to hack something together instead of flooding the list with my questions and to clean it up later. I had problems uploading my code to the repository, as well as to the java.net project I created for this purpose (yes, I guess both times my fault ;) ), so for now I uploaded it to an http-server: http://palme.agosys.com/clemens/xrender-hack-0.0.2.tar.gz It would be really helpful if you could grab the code and have a look at it and tell me all the "don'ts" and how I could solve this or that better. I also attached a list of questions, if you know maybe one or another anwer, please let me know the answer :) Thank you in advance, lg Clemens 1.) I've created a seperate struct to hold the per-surface xrender data structures, similar to ShmPixmapData. I initialize it in JX11SD_InitWindow for windows, because initSurface where I do the xrender-initialization for pixmaps is not called for windows. Is there a better place to do it for windows, maybe unified for both windows and pixmaps? 2.) For now I also leak xrender-resources, because Java_sun_java2d_x11_X11SurfaceData_initOps is also called at window-resize. Whaht should I do about this? Should I store xrender-related data in the peers, like its done with the window-handle? 3.) I am currently using lock/unlock/getrasinfo for MaskFill, is it worth to write seperate upload-routines because of the overhead those functions have (JNI calls, Locking, Xsync, ...)? 4.) In X11SD_InitWindow I've currently RGB24 hardcoded, but I guess this assumption will be wrong once translucent windows are supported by Java. How can I get the surfacetype of a window? 5.) Currently I set the color by passing SunGraphics2D.pixel down to the native library, which premultiplies it. I guess this ?hardcoded" way of doing things is not really good. Is the right way to install an appropriate ColorModel? For premultiplied surfaces I need to specify a ColorSpace, which one is the right for me? 6.) Is there a way to get force a BufferedImage to be cached? For now texturepaints only work when the image has been drawn already, otherwise its not cached any my pipeline can't handle this case. 7.) In X11PMBlitLoops/X11PMTransformedBlit/Transform I simply use the inverted transformation on the source. However this means my drawing area is from 0,0 ->bounds.x/bounds.y. If I don't do it this way, e.g. the rotation point is moved. Is there a way to translate the inverted transform, so that I don't need to composite from 0,0? 8.) I am a bit puzzeled with the problem described at: http://thread.gmane.org/gmane.comp.freedesktop.xorg/30450/focus=30476 Is this a bug, or an unwelcome feature? Any ideas how I can work arround it? I already do clipping the shape-outline however due to rounding errors I either cut something away or get a black thin line. 9.) When scaling images e.g. only on the x-axis, the result is also blurred and smeared over the y-axis. http://article.gmane.org/gmane.comp.freedesktop.xorg/30507 (One of the screenshots is the wrong one, simply have a look for the other images in the album of the right image) Any ideas where this could come from, or how I could avoid it? Setting RepeatPad helps a bit (at least Nimbus looks right), but seems to fall back to software. 10.) Just from a quick look at http://linuxhippy.blogspot.com/2008/07/nimbus_20.html, any ideas what could cause this artifact? It quite struggles me for some time ;) From Dmitri.Trembovetski at Sun.COM Mon Jul 21 17:43:35 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Mon, 21 Jul 2008 10:43:35 -0700 Subject: [OpenJDK 2D-Dev] xrender-pipeline prototype/hack uploaded In-Reply-To: <194f62550807210655v77d56cbdl7e4fdcbfff3bc190@mail.gmail.com> References: <194f62550807210655v77d56cbdl7e4fdcbfff3bc190@mail.gmail.com> Message-ID: <4884CAC7.6070504@Sun.COM> Hi Clemens, Clemens Eisserer wrote: > 1.) I've created a seperate struct to hold the per-surface xrender > data structures, similar to ShmPixmapData. > I initialize it in JX11SD_InitWindow for windows, because initSurface > where I do the xrender-initialization for pixmaps is not called for > windows. > Is there a better place to do it for windows, maybe unified for both > windows and pixmaps? I would indeed suggest to unify your xrender-related initialization so the same code is used to init xrender-related stuff for window and pixmams. From that perspective doing it in InitWindow sounds fine. I assume that you expect both X11 renderer and XRender renderer to be able to render to the same surface, right? > 2.) For now I also leak xrender-resources, because > Java_sun_java2d_x11_X11SurfaceData_initOps is also called at > window-resize. Whaht should I do about this? > Should I store xrender-related data in the peers, like its done with > the window-handle? When window is resized X11SurfaceData is replaced. So you should dispose of your xrender resources for old surface in X11SD_Dispose just like everything else is. A new surface will be created and initialized when needed. > 3.) I am currently using lock/unlock/getrasinfo for MaskFill, is it > worth to write seperate upload-routines because of the overhead those > functions have (JNI calls, Locking, Xsync, ...)? Likely. > 4.) In X11SD_InitWindow I've currently RGB24 hardcoded, but I guess > this assumption will be wrong once translucent windows are supported > by Java. How can I get the surfacetype of a window? You can call getSurfaceType() which is defined in SurfaceData, Or did you mean something different? > 5.) Currently I set the color by passing SunGraphics2D.pixel down to > the native library, which premultiplies it. I guess this ?hardcoded" > way of doing things is not really good. > Is the right way to install an appropriate ColorModel? > For premultiplied surfaces I need to specify a ColorSpace, which one > is the right for me? SurfaceData has an associated SurfaceType, which defines a PixelConverter, which converts rgb to pixels for particular surfae type. So when Graphics.setColor is called, the current surfaceData's pixel converter is called to convert color's rgb to Surface's pixel format. So if your surface has correct surface type the conversion should be done automatically. See how it is done for OGL or D3DSurfaceData classes. > 6.) Is there a way to get force a BufferedImage to be cached? > For now texturepaints only work when the image has been drawn already, > otherwise its not cached any my pipeline can't handle this case. Yes, take a look at D3D/OGLBufImgOps for example. There's a piece of code which forces the surface to be cached: if (!(srcData instanceof D3DSurfaceData)) { // REMIND: this hack tries to ensure that we have a cached texture srcData = dstData.getSourceSurfaceData(img, sg.TRANSFORM_ISIDENT, CompositeType.SrcOver, null); if (!(srcData instanceof D3DSurfaceData)) { return false; } } > 7.) In X11PMBlitLoops/X11PMTransformedBlit/Transform I simply use the > inverted transformation on the source. However this means my drawing > area is from 0,0 ->bounds.x/bounds.y. > If I don't do it this way, e.g. the rotation point is moved. > Is there a way to translate the inverted transform, so that I don't > need to composite from 0,0? Can you elaborate on this one? I don't quite follow. > 8.) I am a bit puzzeled with the problem described at: > http://thread.gmane.org/gmane.comp.freedesktop.xorg/30450/focus=30476 > Is this a bug, or an unwelcome feature? Any ideas how I can work arround it? > I already do clipping the shape-outline however due to rounding errors > I either cut something away or get a black thin line. That looks like xrender bug to me, unless you're using some mode which tells it to update pixels other than those mapped from the source image to the destination. > 9.) When scaling images e.g. only on the x-axis, the result is also > blurred and smeared over the y-axis. > http://article.gmane.org/gmane.comp.freedesktop.xorg/30507 > (One of the screenshots is the wrong one, simply have a look for the > other images in the album of the right image) > Any ideas where this could come from, or how I could avoid it? > Setting RepeatPad helps a bit (at least Nimbus looks right), but seems > to fall back to software. I think it could be caused by incorrect pixel to texel mapping - (or the equivalent in xrender). Basically your pixels don't fall where they should, so filtering is applied. http://msdn.microsoft.com/en-us/library/bb219690.aspx See my comments below for 10. I don't know how much xrender similar to d3d in this regard but it's worth a look. > 10.) Just from a quick look at > http://linuxhippy.blogspot.com/2008/07/nimbus_20.html, any ideas what > could cause this artifact? It quite struggles me for some time ;) Very similar stuff was addressed by these fixes in d3d pipeline and was caused by incorrect pixel to texel mapping: http://bugs.sun.com/view_bug.do?bug_id=6603000 http://bugs.sun.com/view_bug.do?bug_id=6602861 For the fix see SetTransform() method in D3DContext.cpp: http://hg.openjdk.java.net/jdk7/2d/jdk/file/3efc003bf097/src/windows/native/sun/java2d/d3d/D3DContext.cpp You can use this rather exhaustive regression test (from the 2d repo, not yet in the jdk7 master): test/sun/java2d/SunGraphics2D/DrawImageBilinear.java Thanks, Dmitri From Jim.A.Graham at Sun.COM Mon Jul 21 19:32:20 2008 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Mon, 21 Jul 2008 12:32:20 -0700 Subject: [OpenJDK 2D-Dev] Reporitory, Accalerating blits with EA In-Reply-To: <194f62550807160717k40743412j4b5c1e22b2fa2873@mail.gmail.com> References: <194f62550807151528j53b2da19ydbccb641dac5afc1@mail.gmail.com> <194f62550807160717k40743412j4b5c1e22b2fa2873@mail.gmail.com> Message-ID: <0K4D00AG8FK1PQD0@fe-sfbay-09.sun.com> Clemens Eisserer wrote: >> "Extra alpha" has the same behavior for all AlphaComposite instances. In a >> nutshell, the extra alpha value gets logically multiplied with the source >> before the actual compositing operation. The AlphaComposite docs explain >> this process in great detail (look for the A[sub]ac factor): >> http://java.sun.com/javase/6/docs/api/java/awt/AlphaComposite.html > Thanks for the explanation. > I guess the reason for the behaviour I see is a xserver-bug ... I am > not really sure what to do about it till now. One thing that might explain the difference is whether or not the opaque destinations are considered premultiplied or not. I believe that we consider them non-premultiplied in which case the extraalpha is multiplied in, the result is stored to the destination, which involves dividing the alpha back out == no change. If the system treats the destinations as premultiplied then it multiplies the alpha into the color, then stores the multiplied (which looks faded) result into the destination... ...jim From linuxhippy at gmail.com Tue Jul 22 08:24:53 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 22 Jul 2008 10:24:53 +0200 Subject: [OpenJDK 2D-Dev] xrender-pipeline prototype/hack uploaded In-Reply-To: <4884CAC7.6070504@Sun.COM> References: <194f62550807210655v77d56cbdl7e4fdcbfff3bc190@mail.gmail.com> <4884CAC7.6070504@Sun.COM> Message-ID: <194f62550807220124l3f044040y45add89fc22e6de3@mail.gmail.com> Hello Dmitry, > I assume that you expect both X11 renderer and XRender renderer > to be able to render to the same surface, right? If the XRender pipeline is enabled, although it shares the native datastructures with the X11 pipeline, it does not use its drawing functionality, except for copyArea. > When window is resized X11SurfaceData is replaced. So you should > dispose of your xrender resources for old surface in X11SD_Dispose > just like everything else is. A new surface will be created and > initialized when needed. Ah, thanks for the hint :) > You can call getSurfaceType() which is defined in SurfaceData, > Or did you mean something different? Yes this should work. > So if your surface has correct surface type the conversion should > be done automatically. See how it is done for OGL or D3DSurfaceData > classes. I'll have a look, thanks. >> 7.) In X11PMBlitLoops/X11PMTransformedBlit/Transform I simply use the >> inverted transformation on the source. However this means my drawing >> area is from 0,0 ->bounds.x/bounds.y. >> If I don't do it this way, e.g. the rotation point is moved. >> Is there a way to translate the inverted transform, so that I don't >> need to composite from 0,0? > > Can you elaborate on this one? I don't quite follow. XRender does only know about transformations set on the source-pixmap. So when e.g. a rotated image should be drawn, ideally you set the inverse transformation on the source and draw only the rectangular area surrounding the rotated rectangular image. What I do for now is simply inverting the transformation set on Graphics2D, however this transformation is relative to 0,0 and also contains the translation relative to that point, so I also have to specify to start the composition operation at 0,0 - because the inverse transformation will translate the image to the place it belongs. The drawback of this is that a much larger area than really needed is involved in the composite operation: http://picasaweb.google.com/linuxhippy/Transformations/photo#5225748085079311426 I tried to modify the source-transformation, however I always broke it. It worked when shear was positive, but not when negative; the rotation point was moved, .... http://picasaweb.google.com/linuxhippy/Transformations/photo#5225749165321130706 So, instead of composite the whole black area ... would it be possible to adjust the source-transformation so that I would only have to composite the red rectangle, and if yes, how? > >> 8.) I am a bit puzzeled with the problem described at: >> http://thread.gmane.org/gmane.comp.freedesktop.xorg/30450/focus=30476 >> Is this a bug, or an unwelcome feature? Any ideas how I can work arround >> it? >> I already do clipping the shape-outline however due to rounding errors >> I either cut something away or get a black thin line. > > That looks like xrender bug to me, unless you're using some > mode which tells it to update pixels other than those mapped > from the source image to the destination. No, I told XRender I would like to get "RepeatNone". Well this is a rather serious bug because for now it breaks more or less all shear-transformations for single images when XRender is used :-/ > I think it could be caused by incorrect pixel to texel mapping - > (or the equivalent in xrender). Basically your pixels don't > fall where they should, so filtering is applied. > http://msdn.microsoft.com/en-us/library/bb219690.aspx > See my comments below for 10. > > I don't know how much xrender similar to d3d in this regard > but it's worth a look. Thanks a lot for the hint. XRender itself is pixel-based, so the driver has to take care about the mapping. I tried it with XAA (which does transformations using pixman) and the problem was gone. I already reported the problem on the intel-mailinglist. > Very similar stuff was addressed by these fixes in d3d pipeline > and was caused by incorrect pixel to texel mapping: > http://bugs.sun.com/view_bug.do?bug_id=6603000 > http://bugs.sun.com/view_bug.do?bug_id=6602861 > > For the fix see SetTransform() method in D3DContext.cpp: Thanks again for saving me hours of desperate debugging :) Inspired by 9. I tried it woth Xorg-1.5/Intel-2.3.2 and the bug was gone. Thanks a lot for your detaild answers, lg Clemens From linuxhippy at gmail.com Tue Jul 22 10:03:06 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 22 Jul 2008 12:03:06 +0200 Subject: [OpenJDK 2D-Dev] Reporitory, Accalerating blits with EA In-Reply-To: <0K4D00AG8FK1PQD0@fe-sfbay-09.sun.com> References: <194f62550807151528j53b2da19ydbccb641dac5afc1@mail.gmail.com> <194f62550807160717k40743412j4b5c1e22b2fa2873@mail.gmail.com> <0K4D00AG8FK1PQD0@fe-sfbay-09.sun.com> Message-ID: <194f62550807220303t7eed62fex1025636bbac37614@mail.gmail.com> > One thing that might explain the difference is whether or not the opaque > destinations are considered premultiplied or not. I believe that we > consider them non-premultiplied in which case the extraalpha is multiplied > in, the result is stored to the destination, which involves dividing the > alpha back out == no change. If the system treats the destinations as > premultiplied then it multiplies the alpha into the color, then stores the > multiplied (which looks faded) result into the destination... Yes, I guess XRender treats the destination as premultiplied - at least I guess it does not divide out the alpha at all. Thanks a lot for the explanation :) Thanks, Clemens From dmitri.trembovetski at sun.com Tue Jul 22 18:29:16 2008 From: dmitri.trembovetski at sun.com (dmitri.trembovetski at sun.com) Date: Tue, 22 Jul 2008 18:29:16 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6728492: typo in copyrights in some files touched by the d3d pipeline port Message-ID: <20080722182928.AD751D533@hg.openjdk.java.net> Changeset: 2d7068a03750 Author: tdv Date: 2008-07-22 11:24 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2d7068a03750 6728492: typo in copyrights in some files touched by the d3d pipeline port Reviewed-by: prr ! make/common/shared/Platform.gmk ! make/common/shared/Sanity.gmk ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/FILES_export_windows.gmk ! make/sun/awt/Makefile ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/font/FILES_c.gmk ! make/sun/font/Makefile ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/image/DataBuffer.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/share/classes/sun/awt/image/SunVolatileImage.java ! src/share/classes/sun/awt/image/SunWritableRaster.java ! src/share/classes/sun/awt/image/VolatileSurfaceManager.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/loops/BlitBg.java ! src/share/classes/sun/java2d/loops/GeneralRenderer.java ! src/share/classes/sun/java2d/opengl/OGLContext.java ! src/share/classes/sun/java2d/opengl/OGLGraphicsConfig.java ! src/share/classes/sun/java2d/opengl/OGLRenderer.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/share/classes/sun/java2d/pipe/BufferedOpCodes.java ! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/native/sun/font/AccelGlyphCache.c ! src/share/native/sun/font/AccelGlyphCache.h ! src/share/native/sun/java2d/Trace.h ! src/share/native/sun/java2d/loops/BlitBg.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h ! src/share/native/sun/java2d/opengl/OGLContext.c ! src/share/native/sun/java2d/opengl/OGLContext.h ! src/share/native/sun/java2d/opengl/OGLFuncs.h ! src/share/native/sun/java2d/opengl/OGLRenderQueue.c ! src/share/native/sun/java2d/opengl/OGLRenderQueue.h ! src/share/native/sun/java2d/opengl/OGLRenderer.c ! src/share/native/sun/java2d/opengl/OGLRenderer.h ! src/share/native/sun/java2d/opengl/OGLSurfaceData.c ! src/share/native/sun/java2d/opengl/OGLSurfaceData.h ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/classes/sun/awt/motif/MComponentPeer.java ! src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java ! src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java ! src/solaris/classes/sun/java2d/opengl/GLXVolatileSurfaceManager.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/solaris/native/sun/java2d/opengl/GLXGraphicsConfig.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/windows/classes/sun/awt/Win32GraphicsConfig.java ! src/windows/classes/sun/awt/Win32GraphicsDevice.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java ! src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java ! src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java ! src/windows/classes/sun/java2d/windows/GDIBlitLoops.java ! src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java ! src/windows/classes/sun/java2d/windows/WindowsFlags.java ! src/windows/native/sun/java2d/opengl/WGLGraphicsConfig.c ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.h ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.h ! src/windows/native/sun/java2d/windows/WindowsFlags.cpp ! src/windows/native/sun/java2d/windows/WindowsFlags.h ! src/windows/native/sun/windows/Devices.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_DrawingSurface.cpp ! src/windows/native/sun/windows/awt_DrawingSurface.h ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.h ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/awtmsg.h From andrew.brygin at sun.com Fri Jul 25 10:56:05 2008 From: andrew.brygin at sun.com (andrew.brygin at sun.com) Date: Fri, 25 Jul 2008 10:56:05 +0000 Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6687968: PNGImageReader leaks native memory through an Inflater. Message-ID: <20080725105632.14376D7A6@hg.openjdk.java.net> Changeset: 94bcd3503668 Author: bae Date: 2008-07-25 14:46 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/94bcd3503668 6687968: PNGImageReader leaks native memory through an Inflater. Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java From linuxhippy at gmail.com Fri Jul 25 12:31:50 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 25 Jul 2008 14:31:50 +0200 Subject: [OpenJDK 2D-Dev] [OGL] validatePipe and antialiasing Message-ID: <194f62550807250531q1f5fb849sf21730e40ffdaf7@mail.gmail.com> Hello, I am currently trying to rewrite validatePipe using OGLSurfaceData.validatePipe() as template, however I am a bit confused about what happens in the antialiased case, e.g. gradient as paint with antialiasing. E.g. in my case I would like to fallback if the a RadialGradient with focus!=center is set as paint, however OGLSurfaceData.validatePipe() does only call isPaintValid() in the non-antialiased case, however it seems to work fine there. In my case the fallback is only hit when antialiasing is turned off. Thanks for your patience, Clemens From Christopher.Campbell at Sun.COM Fri Jul 25 17:20:22 2008 From: Christopher.Campbell at Sun.COM (Chris Campbell) Date: Fri, 25 Jul 2008 10:20:22 -0700 Subject: [OpenJDK 2D-Dev] [OGL] validatePipe and antialiasing In-Reply-To: <194f62550807250531q1f5fb849sf21730e40ffdaf7@mail.gmail.com> References: <194f62550807250531q1f5fb849sf21730e40ffdaf7@mail.gmail.com> Message-ID: <1CAA8FC3-15BA-4944-83DA-A41923D40E20@sun.com> Hi Clemens, The antialiased case is handled in super.validatePipe() (in the SurfaceData base class), which in turn calls getMaskFill(). We override getMaskFill() in OGLSurfaceData so that it calls OGLPaints.isValid() to determine whether the given paint can be accelerated in the antialiased case. If the paint can't be accelerated by OGL, we return null to indicate that validatePipe() should use a more general/slower path for rendering the paint via MaskBlit. Does this help? Chris On Jul 25, 2008, at 5:31 AM, Clemens Eisserer wrote: > Hello, > > I am currently trying to rewrite validatePipe using > OGLSurfaceData.validatePipe() as template, > however I am a bit confused about what happens in the antialiased > case, e.g. gradient as paint with antialiasing. > > E.g. in my case I would like to fallback if the a RadialGradient with > focus!=center is set as paint, however OGLSurfaceData.validatePipe() > does only call isPaintValid() in the non-antialiased case, however it > seems to work fine there. > In my case the fallback is only hit when antialiasing is turned off. > > Thanks for your patience, Clemens From linuxhippy at gmail.com Fri Jul 25 18:40:34 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 25 Jul 2008 20:40:34 +0200 Subject: [OpenJDK 2D-Dev] [OGL] validatePipe and antialiasing In-Reply-To: <1CAA8FC3-15BA-4944-83DA-A41923D40E20@sun.com> References: <194f62550807250531q1f5fb849sf21730e40ffdaf7@mail.gmail.com> <1CAA8FC3-15BA-4944-83DA-A41923D40E20@sun.com> Message-ID: <194f62550807251140p6ca73ad2uf1ce05b3ff576b05@mail.gmail.com> Hi Chris, > The antialiased case is handled in super.validatePipe() (in the SurfaceData > base class), which in turn calls getMaskFill(). We override getMaskFill() > in OGLSurfaceData so that it calls OGLPaints.isValid() to determine whether > the given paint can be accelerated in the antialiased case. If the paint > can't be accelerated by OGL, we return null to indicate that validatePipe() > should use a more general/slower path for rendering the paint via MaskBlit. Ah yes there it is. Somehow I overlooked that. > Does this help? Yes, thanks a lot - it works now as intended :) Thanks a lot, Clemens From linuxhippy at gmail.com Fri Jul 25 23:06:46 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 26 Jul 2008 01:06:46 +0200 Subject: [OpenJDK 2D-Dev] Initial code drop in xrender-repository Message-ID: <194f62550807251606tca6c6d0xefb287f445443135@mail.gmail.com> Hello, There is now an early version of the xrender pipeline in its repository, the first changeset is located here: http://hg.openjdk.java.net/xrender/xrender/jdk/rev/6d294fa2bd42 Thanks a lot to Dmitri for beeing that helpful, friendly and patient. There are still many things to be done, but the concepts shouldn't change that much. It would be great if you could have a look, I would be happy about suggestions and criticism. To try it out I suggest using at least Xorg-1.5 and a recent version of the intel-driver (I used 2.3.2). There are some bugs in the intel-driver (already reported and confirmed), so if you have problems with rendering artifacts please use XAA. I'll be able to test it on an Radeon-X700M (RV420) on weekend. The nvidia binary driver is missing some xrender hooks (e.g. hurting nimbus a lot), but they are almost finished and should be available soon with a new driver release: http://www.nvnews.net/vbulletin/showthread.php?t=116444 Thanks in advance, Clemens From Dmitri.Trembovetski at Sun.COM Fri Jul 25 23:17:11 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Fri, 25 Jul 2008 16:17:11 -0700 Subject: [OpenJDK 2D-Dev] Initial code drop in xrender-repository In-Reply-To: <194f62550807251606tca6c6d0xefb287f445443135@mail.gmail.com> References: <194f62550807251606tca6c6d0xefb287f445443135@mail.gmail.com> Message-ID: <488A5EF7.2090000@Sun.COM> Congratulations, Clemens! For those who haven't seen his pipeline at work, take a look at his blog - http://linuxhippy.blogspot.com/ . It's pretty impressive, he can even run Java2Demo, Netbeans and SwingSet2, and even with Nimbus =) Thanks, Dmitri Clemens Eisserer wrote: > Hello, > > There is now an early version of the xrender pipeline in its > repository, the first changeset is located here: > http://hg.openjdk.java.net/xrender/xrender/jdk/rev/6d294fa2bd42 > Thanks a lot to Dmitri for beeing that helpful, friendly and patient. > > There are still many things to be done, but the concepts shouldn't > change that much. > It would be great if you could have a look, I would be happy about > suggestions and criticism. > > To try it out I suggest using at least Xorg-1.5 and a recent version > of the intel-driver (I used 2.3.2). > There are some bugs in the intel-driver (already reported and > confirmed), so if you have problems with rendering artifacts please > use XAA. > I'll be able to test it on an Radeon-X700M (RV420) on weekend. > The nvidia binary driver is missing some xrender hooks (e.g. hurting > nimbus a lot), but they are almost finished and should be available > soon with a new driver release: > http://www.nvnews.net/vbulletin/showthread.php?t=116444 > > Thanks in advance, Clemens From linuxhippy at gmail.com Tue Jul 29 02:38:08 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 29 Jul 2008 04:38:08 +0200 Subject: [OpenJDK 2D-Dev] Warning removals In-Reply-To: <194f62550807281934m358b2623kc97ebb1994696f7f@mail.gmail.com> References: <194f62550807281934m358b2623kc97ebb1994696f7f@mail.gmail.com> Message-ID: <194f62550807281938m5cd0ea4dv9860ceaaabc858d2@mail.gmail.com> Hello, I got several warnings when building the X11 pipeline using gcc-4.1.2, most where caused by: - X11SDOps was casted directly from long - GC was casted directly from long There were also a few other small warnings, some too pedantic for my taste. I tried to fix the warnings, modified files are attached (webref was simply too big). lg Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: x11-warnings.tar.bz2 Type: application/x-bzip2 Size: 17631 bytes Desc: not available URL: