From roman.kennke at aicas.com Tue Sep 25 20:43:15 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 25 Sep 2007 22:43:15 +0200 Subject: [OpenJDK 2D-Dev] Remove warnings Message-ID: <1190752995.29921.8.camel@mercury> Today I took some time studying the J2D code [1] and came across a bunch of warnings that I thought I'd remove (only in sun/java2d/x11 for now): - Remove unused imports, makes code slightly cleaner. - Access static fields like SunGraphics2D.XYZ rather than sg2d.XYZ. Better style generally and avoids potential programming error (rarely though). - Add @Override to overriding methods. In case the superclass method changes name and/or signature, this triggers a compiler error, thus preventing accidental problems when refactoring. - Remove some unnecessary casts to String. Makes code slightly cleaner. Find the patch attached. Feel free to include it in OpenJDK if you like. 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-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-java2d-warnings.diff Type: text/x-patch Size: 16317 bytes Desc: not available URL: From linuxhippy at gmail.com Wed Sep 26 15:09:11 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 26 Sep 2007 17:09:11 +0200 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? Message-ID: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> Hi there, I recently found a strange bug while fixing the Mozilla-Browser-Plugin, somehow the Java2d/X11 pipeline has problems with the graybox_error.gif which is shown when an applet fails to initialize. The image is a partially transparent gif which is drawn with a background-color specified. It works for the first time, but at subsequent blits the transparent pixels which should be white are black. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6603887. I played a bit with Java2D's trace functionality that came out: 1.) First draw, rendered correctly: sun.java2d.loops.BlitBg::BlitBg(ByteIndexedBm, SrcNoEa, IntRgb) 2.) Seems like the accaleration-blit: sun.java2d.x11.X11PMBlitLoops$DelegateBlitLoop::Blit(Any, SrcNoEa, "Integer RGB Pixmap with 1-bit transp") sun.java2d.loops.Blit::Blit(ByteIndexed, SrcNoEa, IntRgb) sun.java2d.x11.X11PMBlitBgLoops::BlitBg("Integer RGB Pixmap with 1-bit transp", SrcNoEa, "Integer RGB Pixmap") 3.) subsequent draws only do: sun.java2d.x11.X11PMBlitBgLoops::BlitBg("Integer RGB Pixmap with 1-bit transp", SrcNoEa, "Integer RGB Pixmap") So the interesing opereations seem to habben in 2.) I guess. In X11PMLoops I saw the following comment: /* do an unmasked copy as we've already filled transparent pixels of the source image with the desired color */ XCopyArea(awt_display, srcDrawable, dstXsdo->drawable, dstGC, srcx, srcy, width, height, dstx, dsty); So I guess somehow the filling of the transparent colors with the background-color does something wrong. However I did not find the code where this happens, so some navigation-help would be really appiciated ;) Thank you in advance, lg Clemens From Dmitri.Trembovetski at Sun.COM Wed Sep 26 16:18:06 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 26 Sep 2007 09:18:06 -0700 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> Message-ID: <46FA863E.9040204@Sun.COM> Hi Clemens, do you see the same issue with Java 6 or is it Java 7 specific? Clemens Eisserer wrote: > Hi there, > > I recently found a strange bug while fixing the > Mozilla-Browser-Plugin, somehow the Java2d/X11 pipeline has problems > with the graybox_error.gif which is shown when an applet fails to > initialize. > The image is a partially transparent gif which is drawn with a > background-color specified. It works for the first time, but at > subsequent blits the transparent pixels which should be white are > black. > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6603887. > > I played a bit with Java2D's trace functionality that came out: > > 1.) First draw, rendered correctly: > sun.java2d.loops.BlitBg::BlitBg(ByteIndexedBm, SrcNoEa, IntRgb) > > 2.) Seems like the accaleration-blit: > sun.java2d.x11.X11PMBlitLoops$DelegateBlitLoop::Blit(Any, SrcNoEa, > "Integer RGB Pixmap with 1-bit transp") > sun.java2d.loops.Blit::Blit(ByteIndexed, SrcNoEa, IntRgb) > sun.java2d.x11.X11PMBlitBgLoops::BlitBg("Integer RGB Pixmap with 1-bit > transp", SrcNoEa, "Integer RGB Pixmap") > > 3.) subsequent draws only do: > sun.java2d.x11.X11PMBlitBgLoops::BlitBg("Integer RGB Pixmap with 1-bit > transp", SrcNoEa, "Integer RGB Pixmap") > > So the interesing opereations seem to habben in 2.) I guess. > > In X11PMLoops I saw the following comment: > /* do an unmasked copy as we've already filled transparent > pixels of the source image with the desired color */ > XCopyArea(awt_display, srcDrawable, dstXsdo->drawable, dstGC, > srcx, srcy, width, height, dstx, dsty); > > So I guess somehow the filling of the transparent colors with the > background-color does something wrong. > However I did not find the code where this happens, so some > navigation-help would be really appiciated ;) It happens here during this call: srcDrawable = srcXsdo->GetPixmapWithBg(env, srcXsdo, pixel); Which can be found in X11SurfaceData.c (X11SD_GetPixmapWithBg). Here 'pixel' is the pixel value of the bg color. There were some changes in this area recently in jdk7. My guess would be that we don't initialize the bitmask. In the case of a Blit we call (see X11PMBlitLoops.Blit) updateBitmask(src, dst, src.getColorModel() instanceof IndexColorModel); but I don't see us doing it for the BlitBg. So if you do only BlitBg blits from the image the bitmask will never get initialized. Try adding the updateBitmask call to BlitBg and see if it helps.. Thanks, Dmitri > > Thank you in advance, lg Clemens From linuxhippy at gmail.com Wed Sep 26 16:34:47 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 26 Sep 2007 18:34:47 +0200 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <46FA863E.9040204@Sun.COM> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> <46FA863E.9040204@Sun.COM> Message-ID: <194f62550709260934o527ff85atb0ac3f88ebc177f3@mail.gmail.com> Hi Dmitri, Glad to meet you here! > do you see the same issue with Java 6 or is it > Java 7 specific? I see the same issue since the accalerated X11 pipelines were introduced with Java-1.4 (and up to 1.7.0b19). 1.3.1 always renders correctly. For me its not critical at all, I just thought it would be a good bugfix to contribute. however if you find it, dont hestitate to correct it ;) lg Clemens > > Clemens Eisserer wrote: > > Hi there, > > > > I recently found a strange bug while fixing the > > Mozilla-Browser-Plugin, somehow the Java2d/X11 pipeline has problems > > with the graybox_error.gif which is shown when an applet fails to > > initialize. > > The image is a partially transparent gif which is drawn with a > > background-color specified. It works for the first time, but at > > subsequent blits the transparent pixels which should be white are > > black. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6603887. > > > > I played a bit with Java2D's trace functionality that came out: > > > > 1.) First draw, rendered correctly: > > sun.java2d.loops.BlitBg::BlitBg(ByteIndexedBm, SrcNoEa, IntRgb) > > > > 2.) Seems like the accaleration-blit: > > sun.java2d.x11.X11PMBlitLoops$DelegateBlitLoop::Blit(Any, SrcNoEa, > > "Integer RGB Pixmap with 1-bit transp") > > sun.java2d.loops.Blit::Blit(ByteIndexed, SrcNoEa, IntRgb) > > sun.java2d.x11.X11PMBlitBgLoops::BlitBg("Integer RGB Pixmap with 1-bit > > transp", SrcNoEa, "Integer RGB Pixmap") > > > > 3.) subsequent draws only do: > > sun.java2d.x11.X11PMBlitBgLoops::BlitBg("Integer RGB Pixmap with 1-bit > > transp", SrcNoEa, "Integer RGB Pixmap") > > > > So the interesing opereations seem to habben in 2.) I guess. > > > > In X11PMLoops I saw the following comment: > > /* do an unmasked copy as we've already filled transparent > > pixels of the source image with the desired color */ > > XCopyArea(awt_display, srcDrawable, dstXsdo->drawable, dstGC, > > srcx, srcy, width, height, dstx, dsty); > > > > So I guess somehow the filling of the transparent colors with the > > background-color does something wrong. > > However I did not find the code where this happens, so some > > navigation-help would be really appiciated ;) > > It happens here during this call: > srcDrawable = srcXsdo->GetPixmapWithBg(env, srcXsdo, pixel); > Which can be found in X11SurfaceData.c (X11SD_GetPixmapWithBg). > Here 'pixel' is the pixel value of the bg color. > > There were some changes in this area recently in jdk7. > My guess would be that we don't initialize the bitmask. > In the case of a Blit we call (see X11PMBlitLoops.Blit) > updateBitmask(src, dst, > src.getColorModel() instanceof IndexColorModel); > but I don't see us doing it for the BlitBg. > > So if you do only BlitBg blits from the image the > bitmask will never get initialized. > Try adding the updateBitmask call to BlitBg and see if it helps.. > > Thanks, > Dmitri > > > > > > > Thank you in advance, lg Clemens > From linuxhippy at gmail.com Wed Sep 26 19:24:13 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 26 Sep 2007 21:24:13 +0200 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <194f62550709260934o527ff85atb0ac3f88ebc177f3@mail.gmail.com> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> <46FA863E.9040204@Sun.COM> <194f62550709260934o527ff85atb0ac3f88ebc177f3@mail.gmail.com> Message-ID: <194f62550709261224l16ea18a6t71aebb17cb7b632d@mail.gmail.com> Hello again, I dig a bit deeper and found out that the problem is in X11SurfaceData::X11SD_GetPixmapWithBg. There is an optimization to only modify pixels if the specified background-color differes from the image-transparent color: if (xsdo->bgPixel != pixel + 1) I found out that the problem only appears if I specify Color.WHITE in drawImage every other color works, I wrote some debug-output: xsdo-bgpixel is now: 0 pixel value is:-1 So it seems Java believes that the transparent-color of the image is white while its balck in reality. If I comment out if (xsdo->bgPixel != pixel + 1) it works as intended as it does when specifying any color !=white. Where is xsdo->bgPixel calculated and how does this strange "pixel" value come from ((255, 255, 255) = -1)? Sorry for asking so much, but the code is quite confusing for a newbie... Thank you in advance, lg Clemens From linuxhippy at gmail.com Wed Sep 26 19:49:30 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 26 Sep 2007 21:49:30 +0200 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <194f62550709261224l16ea18a6t71aebb17cb7b632d@mail.gmail.com> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> <46FA863E.9040204@Sun.COM> <194f62550709260934o527ff85atb0ac3f88ebc177f3@mail.gmail.com> <194f62550709261224l16ea18a6t71aebb17cb7b632d@mail.gmail.com> Message-ID: <194f62550709261249x68ea7408yef5eeec1c9efbda6@mail.gmail.com> Hello again, Seems I've identified the bug: _X11SDOps.bgPixel is used as a hint wether the background was already filled with the bgColor specified in drawImage or not - if (xsdo->bgPixel != pixel + 1) it thinks that the transparent pixels of the image have already been painted to the bgColor which works except in the case when pixel = -1, bgColor is always initialized with 0 so for this case the transparent pixels get never ever their color. I now have a few ideas how this could be changed: 1.) Add a jboolean-field to the _X11SDOps struct, indicating wether the bgColor is valid or not. Currently bgColor=0 servers this purpose. It seems to be in my eyes the best approach, however I don't know wether this could break any API/ABI? 2.) Choose a value for the case bgColor==invalid which cannot be taken by a pixel+1 value. As far as I guess the pixel+1 should serve this purpose - never let the pixel become 0 ... but it seems wrong-way thought. Is pixel always a negative value? If yes couldn't the check be replaced with xsdo->bgPixel != pixel)? pixel will never become 0 anyway? Looking foreward to hear your suggestions, lg Clemens From Dmitri.Trembovetski at Sun.COM Thu Sep 27 16:25:43 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 27 Sep 2007 09:25:43 -0700 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <194f62550709261249x68ea7408yef5eeec1c9efbda6@mail.gmail.com> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> <46FA863E.9040204@Sun.COM> <194f62550709260934o527ff85atb0ac3f88ebc177f3@mail.gmail.com> <194f62550709261224l16ea18a6t71aebb17cb7b632d@mail.gmail.com> <194f62550709261249x68ea7408yef5eeec1c9efbda6@mail.gmail.com> Message-ID: <46FBD987.3070305@Sun.COM> Hi Clemens, thanks for getting at the bottom of this. I think you have correctly identified the cause of the problem. Clemens Eisserer wrote: > Hello again, > > Seems I've identified the bug: > _X11SDOps.bgPixel is used as a hint wether the background was already > filled with the bgColor specified in drawImage or not - if > (xsdo->bgPixel != pixel + 1) it thinks that the transparent pixels of > the image have already been painted to the bgColor which works except > in the case when pixel = -1, bgColor is always initialized with 0 so > for this case the transparent pixels get never ever their color. > > I now have a few ideas how this could be changed: > 1.) Add a jboolean-field to the _X11SDOps struct, indicating wether > the bgColor is valid or not. Currently bgColor=0 servers this purpose. > It seems to be in my eyes the best approach, however I don't know > wether this could break any API/ABI? > 2.) Choose a value for the case bgColor==invalid which cannot be taken > by a pixel+1 value. As far as I guess the pixel+1 should serve this > purpose - never let the pixel become 0 ... but it seems wrong-way > thought. > Is pixel always a negative value? If yes couldn't the check be In general, not necessarily - for an 8-bit visual a pixel is an index into a Colormap. > replaced with xsdo->bgPixel != pixel)? pixel will never become 0 > anyway? It may - if the transparent pixel is 0th entry in the colormap. I think we'll have to resort to another boolean which tells whether bgPixel is valid - like you suggested. I have tried to find the code review for this stuff but couldn't - I seem to recall that there was an explanation offered why the +1 trick should work, but I can't remember it. May be Jim can? Thanks, Dmitri > > Looking foreward to hear your suggestions, lg Clemens From Phil.Race at Sun.COM Thu Sep 27 19:18:53 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 27 Sep 2007 12:18:53 -0700 Subject: [OpenJDK 2D-Dev] Remove warnings In-Reply-To: <1190752995.29921.8.camel@mercury> References: <1190752995.29921.8.camel@mercury> Message-ID: <46FC021D.4060702@sun.com> Hi, Roman Kennke wrote: > Today I took some time studying the J2D code [1] and came across a bunch > of warnings that I thought I'd remove (only in sun/java2d/x11 for now): > > - Remove unused imports, makes code slightly cleaner. Someone internally did a sweep recently looking for unused imports but so far as I can tell these weren't covered. > - Access static fields like SunGraphics2D.XYZ rather than sg2d.XYZ. > Better style generally and avoids potential programming error (rarely > though). I suspect that this may have been a mixture of a personal stylistic choice and keeping the line lengths shorter to avoid wrapping or exceeding the 80 chars in our coding standards. Anyone know better? > - Add @Override to overriding methods. In case the superclass method > changes name and/or signature, this triggers a compiler error, thus > preventing accidental problems when refactoring. Most likely we could find thousands of such cases which pre-date annotations. Does anyone know if there is a tool to (semi)automate this? -phil. > - Remove some unnecessary casts to String. Makes code slightly cleaner. > > Find the patch attached. Feel free to include it in OpenJDK if you like. > > Cheers, Roman > > > ------------------------------------------------------------------------ > > Index: j2se/src/solaris/classes/sun/java2d/x11/X11Renderer.java > =================================================================== > --- j2se/src/solaris/classes/sun/java2d/x11/X11Renderer.java (Revision 252) > +++ j2se/src/solaris/classes/sun/java2d/x11/X11Renderer.java (Arbeitskopie) > @@ -28,12 +28,9 @@ > import java.awt.Polygon; > import java.awt.Shape; > import java.awt.geom.AffineTransform; > -import java.awt.geom.PathIterator; > import java.awt.geom.Path2D; > -import java.awt.geom.IllegalPathStateException; > import sun.awt.SunToolkit; > import sun.java2d.SunGraphics2D; > -import sun.java2d.SurfaceData; > import sun.java2d.loops.GraphicsPrimitive; > import sun.java2d.pipe.Region; > import sun.java2d.pipe.PixelDrawPipe; > @@ -299,7 +296,7 @@ > private void doPath(SunGraphics2D sg2d, Shape s, boolean isFill) { > Path2D.Float p2df; > int transx, transy; > - if (sg2d.transformState <= sg2d.TRANSFORM_INT_TRANSLATE) { > + if (sg2d.transformState <= SunGraphics2D.TRANSFORM_INT_TRANSLATE) { > if (s instanceof Path2D.Float) { > p2df = (Path2D.Float)s; > } else { > @@ -323,10 +320,10 @@ > } > > public void draw(SunGraphics2D sg2d, Shape s) { > - if (sg2d.strokeState == sg2d.STROKE_THIN) { > + if (sg2d.strokeState == SunGraphics2D.STROKE_THIN) { > // Delegate to drawPolygon() if possible... > if (s instanceof Polygon && > - sg2d.transformState < sg2d.TRANSFORM_TRANSLATESCALE) > + sg2d.transformState < SunGraphics2D.TRANSFORM_TRANSLATESCALE) > { > Polygon p = (Polygon) s; > drawPolygon(sg2d, p.xpoints, p.ypoints, p.npoints); > @@ -336,7 +333,7 @@ > // Otherwise we will use drawPath() for > // high-quality thin paths. > doPath(sg2d, s, false); > - } else if (sg2d.strokeState < sg2d.STROKE_CUSTOM) { > + } else if (sg2d.strokeState < SunGraphics2D.STROKE_CUSTOM) { > // REMIND: X11 can handle uniform scaled wide lines > // and dashed lines itself if we set the appropriate > // XGC attributes (TBD). > @@ -360,10 +357,10 @@ > } > > public void fill(SunGraphics2D sg2d, Shape s) { > - if (sg2d.strokeState == sg2d.STROKE_THIN) { > + if (sg2d.strokeState == SunGraphics2D.STROKE_THIN) { > // Delegate to fillPolygon() if possible... > if (s instanceof Polygon && > - sg2d.transformState < sg2d.TRANSFORM_TRANSLATESCALE) > + sg2d.transformState < SunGraphics2D.TRANSFORM_TRANSLATESCALE) > { > Polygon p = (Polygon) s; > fillPolygon(sg2d, p.xpoints, p.ypoints, p.npoints); > @@ -378,7 +375,7 @@ > > AffineTransform at; > int transx, transy; > - if (sg2d.transformState < sg2d.TRANSFORM_TRANSLATESCALE) { > + if (sg2d.transformState < SunGraphics2D.TRANSFORM_TRANSLATESCALE) { > // Transform (translation) will be done by XFillSpans > at = null; > transx = sg2d.transX; > @@ -419,18 +416,21 @@ > int w, int h); > > public static class X11TracingRenderer extends X11Renderer { > + @Override > void XDrawLine(long pXSData, long xgc, > int x1, int y1, int x2, int y2) > { > GraphicsPrimitive.tracePrimitive("X11DrawLine"); > super.XDrawLine(pXSData, xgc, x1, y1, x2, y2); > } > + @Override > void XDrawRect(long pXSData, long xgc, > int x, int y, int w, int h) > { > GraphicsPrimitive.tracePrimitive("X11DrawRect"); > super.XDrawRect(pXSData, xgc, x, y, w, h); > } > + @Override > void XDrawRoundRect(long pXSData, long xgc, > int x, int y, int w, int h, > int arcW, int arcH) > @@ -438,12 +438,14 @@ > GraphicsPrimitive.tracePrimitive("X11DrawRoundRect"); > super.XDrawRoundRect(pXSData, xgc, x, y, w, h, arcW, arcH); > } > + @Override > void XDrawOval(long pXSData, long xgc, > int x, int y, int w, int h) > { > GraphicsPrimitive.tracePrimitive("X11DrawOval"); > super.XDrawOval(pXSData, xgc, x, y, w, h); > } > + @Override > void XDrawArc(long pXSData, long xgc, > int x, int y, int w, int h, > int angleStart, int angleExtent) > @@ -452,6 +454,7 @@ > super.XDrawArc(pXSData, xgc, > x, y, w, h, angleStart, angleExtent); > } > + @Override > void XDrawPoly(long pXSData, long xgc, > int transx, int transy, > int[] xpoints, int[] ypoints, > @@ -461,6 +464,7 @@ > super.XDrawPoly(pXSData, xgc, transx, transy, > xpoints, ypoints, npoints, isclosed); > } > + @Override > void XDoPath(SunGraphics2D sg2d, long pXSData, long xgc, > int transX, int transY, Path2D.Float p2df, > boolean isFill) > @@ -470,12 +474,14 @@ > "X11DrawPath"); > super.XDoPath(sg2d, pXSData, xgc, transX, transY, p2df, isFill); > } > + @Override > void XFillRect(long pXSData, long xgc, > int x, int y, int w, int h) > { > GraphicsPrimitive.tracePrimitive("X11FillRect"); > super.XFillRect(pXSData, xgc, x, y, w, h); > } > + @Override > void XFillRoundRect(long pXSData, long xgc, > int x, int y, int w, int h, > int arcW, int arcH) > @@ -483,12 +489,14 @@ > GraphicsPrimitive.tracePrimitive("X11FillRoundRect"); > super.XFillRoundRect(pXSData, xgc, x, y, w, h, arcW, arcH); > } > + @Override > void XFillOval(long pXSData, long xgc, > int x, int y, int w, int h) > { > GraphicsPrimitive.tracePrimitive("X11FillOval"); > super.XFillOval(pXSData, xgc, x, y, w, h); > } > + @Override > void XFillArc(long pXSData, long xgc, > int x, int y, int w, int h, > int angleStart, int angleExtent) > @@ -497,6 +505,7 @@ > super.XFillArc(pXSData, xgc, > x, y, w, h, angleStart, angleExtent); > } > + @Override > void XFillPoly(long pXSData, long xgc, > int transx, int transy, > int[] xpoints, int[] ypoints, > @@ -506,6 +515,7 @@ > super.XFillPoly(pXSData, xgc, > transx, transy, xpoints, ypoints, npoints); > } > + @Override > void XFillSpans(long pXSData, long xgc, > SpanIterator si, long iterator, int transx, int transy) > { > @@ -513,6 +523,7 @@ > super.XFillSpans(pXSData, xgc, > si, iterator, transx, transy); > } > + @Override > void devCopyArea(long sdOps, long xgc, > int srcx, int srcy, > int dstx, int dsty, > Index: j2se/src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java > =================================================================== > --- j2se/src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java (Revision 252) > +++ j2se/src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java (Arbeitskopie) > @@ -79,6 +79,7 @@ > super(srcType, CompositeType.SrcNoEa, dstType); > } > > + @Override > public void BlitBg(SurfaceData src, SurfaceData dst, > Composite comp, Region clip, Color bgColor, > int sx, int sy, > Index: j2se/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java > =================================================================== > --- j2se/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java (Revision 252) > +++ j2se/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java (Arbeitskopie) > @@ -27,20 +27,17 @@ > > import java.awt.GraphicsDevice; > import java.awt.GraphicsEnvironment; > -import java.awt.Color; > import java.awt.Composite; > import java.awt.Rectangle; > import java.awt.GraphicsConfiguration; > import java.awt.Image; > import java.awt.color.ColorSpace; > import java.awt.Transparency; > -import java.awt.image.BufferedImage; > import java.awt.image.ColorModel; > import java.awt.image.ComponentColorModel; > import java.awt.image.DirectColorModel; > import java.awt.image.IndexColorModel; > import java.awt.image.Raster; > -import java.awt.peer.ComponentPeer; > > import sun.awt.SunHints; > import sun.awt.SunToolkit; > @@ -57,7 +54,6 @@ > import sun.java2d.loops.RenderLoops; > import sun.java2d.loops.GraphicsPrimitive; > import sun.java2d.loops.XORComposite; > -import sun.java2d.loops.Blit; > import sun.java2d.pipe.ValidatePipe; > import sun.java2d.pipe.PixelToShapeConverter; > import sun.java2d.pipe.TextPipe; > @@ -201,13 +197,13 @@ > static { > if (!GraphicsEnvironment.isHeadless()) { > // If a screen magnifier is present, don't attempt to use DGA > - String magPresent = (String) java.security.AccessController.doPrivileged > + String magPresent = java.security.AccessController.doPrivileged > (new sun.security.action.GetPropertyAction("javax.accessibility.screen_magnifier_present")); > boolean tryDGA = magPresent == null || !"true".equals(magPresent); > > initIDs(XORComposite.class, tryDGA); > > - String xtextpipe = (String) java.security.AccessController.doPrivileged > + String xtextpipe = java.security.AccessController.doPrivileged > (new sun.security.action.GetPropertyAction("sun.java2d.xtextpipe")); > if (xtextpipe == null || "true".startsWith(xtextpipe)) { > if ("true".equals(xtextpipe)) { > @@ -246,8 +242,7 @@ > if (GraphicsEnvironment.isHeadless()) { > accelerationEnabled = Boolean.FALSE; > } else { > - String prop = > - (String) java.security.AccessController.doPrivileged( > + String prop = java.security.AccessController.doPrivileged( > new sun.security.action.GetPropertyAction("sun.java2d.pmoffscreen")); > if (prop != null) { > // true iff prop==true, false otherwise > @@ -266,11 +261,12 @@ > return X11SurfaceDataProxy.createProxy(srcData, graphicsConfig); > } > > + @Override > public void validatePipe(SunGraphics2D sg2d) { > if (sg2d.antialiasHint != SunHints.INTVAL_ANTIALIAS_ON && > - sg2d.paintState <= sg2d.PAINT_ALPHACOLOR && > - (sg2d.compositeState <= sg2d.COMP_ISCOPY || > - sg2d.compositeState == sg2d.COMP_XOR)) > + sg2d.paintState <= SunGraphics2D.PAINT_ALPHACOLOR && > + (sg2d.compositeState <= SunGraphics2D.COMP_ISCOPY || > + sg2d.compositeState == SunGraphics2D.COMP_XOR)) > { > if (x11txpipe == null) { > /* > @@ -288,7 +284,7 @@ > return; > } > > - if (sg2d.clipState == sg2d.CLIP_SHAPE) { > + if (sg2d.clipState == SunGraphics2D.CLIP_SHAPE) { > // Do this to init textpipe correctly; we will override the > // other non-text pipes below > // REMIND: we should clean this up eventually instead of > @@ -302,7 +298,7 @@ > case SunHints.INTVAL_TEXT_ANTIALIAS_OFF: > // Use X11 pipe even if DGA is available since DGA > // text slows everything down when mixed with X11 calls > - if (sg2d.compositeState == sg2d.COMP_ISCOPY) { > + if (sg2d.compositeState == SunGraphics2D.COMP_ISCOPY) { > sg2d.textpipe = x11textpipe; > } else { > sg2d.textpipe = solidTextRenderer; > @@ -326,7 +322,7 @@ > case SunHints.INTVAL_TEXT_ANTIALIAS_OFF: > // Use X11 pipe even if DGA is available since DGA > // text slows everything down when mixed with X11 calls > - if (sg2d.compositeState == sg2d.COMP_ISCOPY) { > + if (sg2d.compositeState == SunGraphics2D.COMP_ISCOPY) { > sg2d.textpipe = x11textpipe; > } else { > sg2d.textpipe = solidTextRenderer; > @@ -343,10 +339,10 @@ > } > } > > - if (sg2d.transformState >= sg2d.TRANSFORM_TRANSLATESCALE) { > + if (sg2d.transformState >= SunGraphics2D.TRANSFORM_TRANSLATESCALE) { > sg2d.drawpipe = x11txpipe; > sg2d.fillpipe = x11txpipe; > - } else if (sg2d.strokeState != sg2d.STROKE_THIN){ > + } else if (sg2d.strokeState != SunGraphics2D.STROKE_THIN){ > sg2d.drawpipe = x11txpipe; > sg2d.fillpipe = x11pipe; > } else { > @@ -367,9 +363,10 @@ > } > } > > + @Override > public RenderLoops getRenderLoops(SunGraphics2D sg2d) { > - if (sg2d.paintState <= sg2d.PAINT_ALPHACOLOR && > - sg2d.compositeState <= sg2d.COMP_ISCOPY) > + if (sg2d.paintState <= SunGraphics2D.PAINT_ALPHACOLOR && > + sg2d.compositeState <= SunGraphics2D.COMP_ISCOPY) > { > return solidloops; > } > @@ -448,6 +445,7 @@ > */ > public abstract boolean canSourceSendExposures(int x, int y, int w, int h); > > + @Override > public boolean copyArea(SunGraphics2D sg2d, > int x, int y, int w, int h, int dx, int dy) > { > @@ -458,7 +456,7 @@ > makePipes(); > } > CompositeType comptype = sg2d.imageComp; > - if (sg2d.transformState < sg2d.TRANSFORM_TRANSLATESCALE && > + if (sg2d.transformState < SunGraphics2D.TRANSFORM_TRANSLATESCALE && > (CompositeType.SrcOverNoEa.equals(comptype) || > CompositeType.SrcNoEa.equals(comptype))) > { > @@ -467,8 +465,8 @@ > SunToolkit.awtLock(); > try { > boolean needExposures = canSourceSendExposures(x, y, w, h); > - long xgc = getBlitGC(sg2d.getCompClip(), needExposures); > - x11pipe.devCopyArea(getNativeOps(), xgc, > + long _xgc = getBlitGC(sg2d.getCompClip(), needExposures); > + x11pipe.devCopyArea(getNativeOps(), _xgc, > x, y, > x + dx, y + dy, > w, h); > @@ -567,6 +565,7 @@ > > public native void setInvalid(); > > + @Override > public void invalidate() { > if (isValid()) { > setInvalid(); > @@ -743,6 +742,7 @@ > * it could choose wrong loop (blit instead of blitbg, > * for example). > */ > + @Override > public int getTransparency() { > return transparency; > } > @@ -756,6 +756,7 @@ > return (x < 0 || y < 0 || (x+w) > width || (y+h) > height); > } > > + @Override > public void flush() { > /* > * We need to invalidate the surface before disposing the > @@ -780,6 +781,7 @@ > private static LazyPipe lazypipe = new LazyPipe(); > > public static class LazyPipe extends ValidatePipe { > + @Override > public boolean validate(SunGraphics2D sg2d) { > X11SurfaceData xsd = (X11SurfaceData) sg2d.surfaceData; > if (!xsd.isDrawableValid()) { > Index: j2se/src/solaris/classes/sun/java2d/x11/X11VolatileSurfaceManager.java > =================================================================== > --- j2se/src/solaris/classes/sun/java2d/x11/X11VolatileSurfaceManager.java (Revision 252) > +++ j2se/src/solaris/classes/sun/java2d/x11/X11VolatileSurfaceManager.java (Arbeitskopie) > @@ -103,6 +103,7 @@ > return sData; > } > > + @Override > protected boolean isConfigValid(GraphicsConfiguration gc) { > // REMIND: we might be too paranoid here, requiring that > // the GC be exactly the same as the original one. The > Index: j2se/src/solaris/classes/sun/java2d/x11/X11SurfaceDataProxy.java > =================================================================== > --- j2se/src/solaris/classes/sun/java2d/x11/X11SurfaceDataProxy.java (Revision 252) > +++ j2se/src/solaris/classes/sun/java2d/x11/X11SurfaceDataProxy.java (Arbeitskopie) > @@ -26,8 +26,6 @@ > package sun.java2d.x11; > > import java.awt.Color; > -import java.awt.AlphaComposite; > -import java.awt.GraphicsConfiguration; > import java.awt.Transparency; > import java.awt.image.ColorModel; > import java.awt.image.IndexColorModel; > Index: j2se/src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java > =================================================================== > --- j2se/src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java (Revision 252) > +++ j2se/src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java (Arbeitskopie) > @@ -28,11 +28,9 @@ > import sun.awt.SunToolkit; > import sun.java2d.loops.GraphicsPrimitive; > import sun.java2d.loops.GraphicsPrimitiveMgr; > -import sun.java2d.loops.GraphicsPrimitiveProxy; > import sun.java2d.loops.CompositeType; > import sun.java2d.loops.SurfaceType; > import sun.java2d.loops.Blit; > -import sun.java2d.loops.MaskBlit; > import sun.java2d.pipe.Region; > import sun.java2d.SurfaceData; > import java.awt.Composite; > @@ -128,6 +126,7 @@ > dstType); > } > > + @Override > public void Blit(SurfaceData src, SurfaceData dst, > Composite comp, Region clip, > int sx, int sy, > @@ -178,6 +177,7 @@ > this.dstType = delegateDstType; > } > > + @Override > public void Blit(SurfaceData src, SurfaceData dst, > Composite comp, Region clip, > int sx, int sy, int dx, int dy, int w, int h) From roman.kennke at aicas.com Thu Sep 27 20:13:28 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Thu, 27 Sep 2007 22:13:28 +0200 Subject: [OpenJDK 2D-Dev] Remove warnings In-Reply-To: <46FC021D.4060702@sun.com> References: <1190752995.29921.8.camel@mercury> <46FC021D.4060702@sun.com> Message-ID: <1190924008.7478.23.camel@mercury> Hi Phil, > > - Access static fields like SunGraphics2D.XYZ rather than sg2d.XYZ. > > Better style generally and avoids potential programming error (rarely > > though). > > I suspect that this may have been a mixture of a personal stylistic > choice and keeping the line lengths shorter to avoid wrapping or exceeding > the 80 chars in our coding standards. Anyone know better? In those cases the 80 chars limit has not been exceeded (I let my IDEs show the 80 chars limit to avoid such problems). > > - Add @Override to overriding methods. In case the superclass method > > changes name and/or signature, this triggers a compiler error, thus > > preventing accidental problems when refactoring. > > Most likely we could find thousands of such cases which pre-date > annotations. Does anyone know if there is a tool to (semi)automate this? That would be a very useful tool. I'd be interested too. 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-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From mlists at juma.me.uk Thu Sep 27 20:37:46 2007 From: mlists at juma.me.uk (Ismael Juma) Date: Thu, 27 Sep 2007 20:37:46 +0000 (UTC) Subject: [OpenJDK 2D-Dev] Remove warnings References: <1190752995.29921.8.camel@mercury> <46FC021D.4060702@sun.com> Message-ID: Phil Race writes: > Most likely we could find thousands of such cases which pre-date > annotations. Does anyone know if there is a tool to (semi)automate this? You can use eclipse and the clean-up wizard (Source -> Clean-up) to do this and many other things (missing @Deprecated, remove trailing white spaces, indirect static usage, unused imports, remove unnecessary cast, etc.). If you were looking for a tool that is not an IDE, then I don't know. :) Ismael From roman.kennke at aicas.com Fri Sep 28 07:29:14 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Fri, 28 Sep 2007 09:29:14 +0200 Subject: [OpenJDK 2D-Dev] Status of java.awt.image ? Message-ID: <1190964554.6026.7.camel@mercury> Hi folks, What is the status of the java.awt.image classes? Is there anything I can do about them? Most of the classes are not too hard to implement, I could come up with cleanroom implementations relatively fast if you like. /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-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From linuxhippy at gmail.com Fri Sep 28 10:42:02 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 28 Sep 2007 12:42:02 +0200 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <46FBD987.3070305@Sun.COM> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> <46FA863E.9040204@Sun.COM> <194f62550709260934o527ff85atb0ac3f88ebc177f3@mail.gmail.com> <194f62550709261224l16ea18a6t71aebb17cb7b632d@mail.gmail.com> <194f62550709261249x68ea7408yef5eeec1c9efbda6@mail.gmail.com> <46FBD987.3070305@Sun.COM> Message-ID: <194f62550709280342x482fb5d6g24ece43147b1637c@mail.gmail.com> Hi, > It may - if the transparent pixel is 0th entry in the colormap. > > I think we'll have to resort to another boolean which tells > whether bgPixel is valid - like you suggested. Yes, I also think this would be a better fix, and it would make the source more readable in my opinion. I copied my first attemp to fix the problem below. lg Clemens PS: Thanks for open-sourcing java! --- /home/ce/mozilla_java_prob/jdk7_original/j2se/src/solaris/native/sun/java2d/x11/X11SurfaceData.c 2007-09-12 20:11:42.000000000 +0200 +++ /home/ce/mozilla_java_prob/jdk7_modified/j2se/src/solaris/native/sun/java2d/x11/X11SurfaceData.c 2007-09-28 12:25:19.000000000 +0200 @@ -256,6 +256,7 @@ xsdo->isPixmap = JNI_FALSE; xsdo->bitmask = 0; xsdo->bgPixel = 0; + xsdo->isBgInitialized = JNI_FALSE; #ifdef MITSHM xsdo->shmPMData.shmSegInfo = NULL; xsdo->shmPMData.xRequestSent = JNI_FALSE; @@ -997,7 +998,7 @@ } /* the background pixel is not valid anymore */ if (xpriv->lockFlags & SD_LOCK_WRITE) { - xsdo->bgPixel = 0; + xsdo->isBgInitialized = JNI_FALSE; } xpriv->lockType = X11SD_LOCK_UNLOCKED; AWT_UNLOCK(); @@ -1485,7 +1486,7 @@ /* Check if current color of the transparent pixels is different from the specified one */ - if (xsdo->bgPixel != pixel + 1) { + if (xsdo->bgPixel != pixel || xsdo->isBgInitialized == JNI_FALSE) { GC srcGC; GC bmGC; @@ -1525,7 +1526,8 @@ XFreeGC(awt_display, bmGC); XFreeGC(awt_display, srcGC); - xsdo->bgPixel = pixel + 1; + xsdo->bgPixel = pixel; + xsdo->isBgInitialized = JNI_TRUE; } return xsdo->drawable; --- /home/ce/mozilla_java_prob/jdk7_original/j2se/src/solaris/native/sun/java2d/x11/X11SurfaceData.h 2007-09-12 20:11:42.000000000 +0200 +++ /home/ce/mozilla_java_prob/jdk7_modified/j2se/src/solaris/native/sun/java2d/x11/X11SurfaceData.h 2007-09-28 12:22:45.000000000 +0200 @@ -107,6 +107,7 @@ void *dgaDev; Pixmap bitmask; jint bgPixel; /* bg pixel for the pixmap */ + jboolean isBgInitialized; jint pmWidth; /* width, height of the */ jint pmHeight; /* pixmap */ #ifdef MITSHM From Phil.Race at Sun.COM Fri Sep 28 14:02:45 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Fri, 28 Sep 2007 07:02:45 -0700 Subject: [OpenJDK 2D-Dev] Status of java.awt.image ? In-Reply-To: <1190964554.6026.7.camel@mercury> References: <1190964554.6026.7.camel@mercury> Message-ID: <46FD0985.9040805@sun.com> Roman, We know this is doable, but this could yet be resolved such that we can simply move the classes to open. So we've held off doing any potentially wasted work until we get an answer - which is taking a whole lot longer than any of us would like. BTW the 2D list is the correct one for this topic. -phil. Roman Kennke wrote: > Hi folks, > > What is the status of the java.awt.image classes? Is there anything I > can do about them? Most of the classes are not too hard to implement, I > could come up with cleanroom implementations relatively fast if you > like. > > /Roman > > From Dmitri.Trembovetski at Sun.COM Fri Sep 28 16:37:10 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Fri, 28 Sep 2007 09:37:10 -0700 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <194f62550709280342x482fb5d6g24ece43147b1637c@mail.gmail.com> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> <46FA863E.9040204@Sun.COM> <194f62550709260934o527ff85atb0ac3f88ebc177f3@mail.gmail.com> <194f62550709261224l16ea18a6t71aebb17cb7b632d@mail.gmail.com> <194f62550709261249x68ea7408yef5eeec1c9efbda6@mail.gmail.com> <46FBD987.3070305@Sun.COM> <194f62550709280342x482fb5d6g24ece43147b1637c@mail.gmail.com> Message-ID: <46FD2DB6.7090509@Sun.COM> Hi Clemens, thanks for the suggested fix. It looks fine to me so I could integrate it for you providing there are no issues found by other reviewers. Could you produce an automated regression test? Just construct an 8-bit image with white as transparent color, render it to a some-color-filled VI, then get a snapshot and check that the color of the VI didn't change. If it did, throw a RuntimeError.. If we do it quickly (like, today) we can integrate it into the next build.. Thanks, Dmitri Clemens Eisserer wrote: > Hi, > >> It may - if the transparent pixel is 0th entry in the colormap. >> >> I think we'll have to resort to another boolean which tells >> whether bgPixel is valid - like you suggested. > Yes, I also think this would be a better fix, and it would make the > source more readable in my opinion. > > I copied my first attemp to fix the problem below. > > lg Clemens > > PS: Thanks for open-sourcing java! > > --- /home/ce/mozilla_java_prob/jdk7_original/j2se/src/solaris/native/sun/java2d/x11/X11SurfaceData.c > 2007-09-12 20:11:42.000000000 +0200 > +++ /home/ce/mozilla_java_prob/jdk7_modified/j2se/src/solaris/native/sun/java2d/x11/X11SurfaceData.c > 2007-09-28 12:25:19.000000000 +0200 > @@ -256,6 +256,7 @@ > xsdo->isPixmap = JNI_FALSE; > xsdo->bitmask = 0; > xsdo->bgPixel = 0; > + xsdo->isBgInitialized = JNI_FALSE; > #ifdef MITSHM > xsdo->shmPMData.shmSegInfo = NULL; > xsdo->shmPMData.xRequestSent = JNI_FALSE; > @@ -997,7 +998,7 @@ > } > /* the background pixel is not valid anymore */ > if (xpriv->lockFlags & SD_LOCK_WRITE) { > - xsdo->bgPixel = 0; > + xsdo->isBgInitialized = JNI_FALSE; > } > xpriv->lockType = X11SD_LOCK_UNLOCKED; > AWT_UNLOCK(); > @@ -1485,7 +1486,7 @@ > > /* Check if current color of the transparent pixels is different > from the specified one */ > - if (xsdo->bgPixel != pixel + 1) { > + if (xsdo->bgPixel != pixel || xsdo->isBgInitialized == JNI_FALSE) { > GC srcGC; > GC bmGC; > > @@ -1525,7 +1526,8 @@ > > XFreeGC(awt_display, bmGC); > XFreeGC(awt_display, srcGC); > - xsdo->bgPixel = pixel + 1; > + xsdo->bgPixel = pixel; > + xsdo->isBgInitialized = JNI_TRUE; > } > > return xsdo->drawable; > > > --- /home/ce/mozilla_java_prob/jdk7_original/j2se/src/solaris/native/sun/java2d/x11/X11SurfaceData.h > 2007-09-12 20:11:42.000000000 +0200 > +++ /home/ce/mozilla_java_prob/jdk7_modified/j2se/src/solaris/native/sun/java2d/x11/X11SurfaceData.h > 2007-09-28 12:22:45.000000000 +0200 > @@ -107,6 +107,7 @@ > void *dgaDev; > Pixmap bitmask; > jint bgPixel; /* bg pixel for the pixmap */ > + jboolean isBgInitialized; > jint pmWidth; /* width, height of the */ > jint pmHeight; /* pixmap */ > #ifdef MITSHM From linuxhippy at gmail.com Fri Sep 28 17:26:12 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 28 Sep 2007 19:26:12 +0200 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <46FD2DB6.7090509@Sun.COM> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> <46FA863E.9040204@Sun.COM> <194f62550709260934o527ff85atb0ac3f88ebc177f3@mail.gmail.com> <194f62550709261224l16ea18a6t71aebb17cb7b632d@mail.gmail.com> <194f62550709261249x68ea7408yef5eeec1c9efbda6@mail.gmail.com> <46FBD987.3070305@Sun.COM> <194f62550709280342x482fb5d6g24ece43147b1637c@mail.gmail.com> <46FD2DB6.7090509@Sun.COM> Message-ID: <194f62550709281026q1a1bace9y4a2d5c8ead3b1ca0@mail.gmail.com> Hi Dimitri, I hope the test fits your/the needs, I was not able to produce an image that triggers the problem so I simply used the graybox_error.gif - it does not contain black (which the uninitialized areas are painted) so I can simply check for that. However it depends one some assumptions (VI is accalerated, blitting two times leads to accaleration, ??). lg Clemens Thanks for open-sourcing java :) The test: import java.awt.*; import java.awt.image.*; import javax.swing.*; public class BgRegTest { public static void main(String[] args) { JFrame testFrame = new JFrame(); testFrame.setVisible(true); /* * Set up images: * 1.) VolatileImge for rendering to, * 2.) BufferedImage for reading back the contents of the VI * 3.) The image triggering the problem */ VolatileImage vImg = null; BufferedImage readBackBImg = new BufferedImage(25, 25, BufferedImage.TYPE_INT_RGB); Image tImg = new ImageIcon(testFrame.getClass().getResource("/graybox_error.gif")).getImage(); Graphics readBackG = readBackBImg.getGraphics(); do { if (vImg == null || vImg.validate(testFrame.getGraphicsConfiguration()) == VolatileImage.IMAGE_INCOMPATIBLE) { vImg = testFrame.createVolatileImage(25, 25); } Graphics viG = vImg.getGraphics(); viG.setColor(Color.white); viG.fillRect(0, 0, 25, 25); //Blit it at least two times to make sure it becomes accalerated - This is an assumption and may break if implementation changes viG.drawImage(tImg, 0, 0, Color.white, testFrame); viG.drawImage(tImg, 0, 0, Color.white, testFrame); readBackG.drawImage(vImg, 0, 0, testFrame); } while (vImg.contentsLost()); //Check wether un-initialized pixels (black) exist for (int x = 0; x < readBackBImg.getWidth(); x++) { for (int y = 0; y < readBackBImg.getHeight(); y++) { int currPixel = readBackBImg.getRGB(x, y); if (currPixel == Color.black.getRGB()) { throw new RuntimeException("Background has changed!"); } } } } } From Dmitri.Trembovetski at Sun.COM Fri Sep 28 20:06:59 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Fri, 28 Sep 2007 13:06:59 -0700 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <194f62550709281026q1a1bace9y4a2d5c8ead3b1ca0@mail.gmail.com> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> <46FA863E.9040204@Sun.COM> <194f62550709260934o527ff85atb0ac3f88ebc177f3@mail.gmail.com> <194f62550709261224l16ea18a6t71aebb17cb7b632d@mail.gmail.com> <194f62550709261249x68ea7408yef5eeec1c9efbda6@mail.gmail.com> <46FBD987.3070305@Sun.COM> <194f62550709280342x482fb5d6g24ece43147b1637c@mail.gmail.com> <46FD2DB6.7090509@Sun.COM> <194f62550709281026q1a1bace9y4a2d5c8ead3b1ca0@mail.gmail.com> Message-ID: <46FD5EE3.7020201@Sun.COM> Hi Clemens, I'm having issues with reproducing the bug with this or the original test. I've tried on solaris and linux, it works fine in both cases on all jdks I've tried. Weird. In the debugger I see that the pixel passed to X11SD_GetPixmapWithBg is 0x00ffffff, not 0xffffffff, so pixel+1 != 0 . What is your desktop bit depth? I've tried on 24bit systems. Thanks, Dmitri Clemens Eisserer wrote: > Hi Dimitri, > > I hope the test fits your/the needs, I was not able to produce an > image that triggers the problem so I simply used the graybox_error.gif > - it does not contain black (which the uninitialized areas are > painted) so I can simply check for that. > However it depends one some assumptions (VI is accalerated, blitting > two times leads to accaleration, ??). > > lg Clemens > Thanks for open-sourcing java :) > > The test: > import java.awt.*; > import java.awt.image.*; > > import javax.swing.*; > > public class BgRegTest > { > public static void main(String[] args) > { > JFrame testFrame = new JFrame(); > testFrame.setVisible(true); > > /* > * Set up images: > * 1.) VolatileImge for rendering to, > * 2.) BufferedImage for reading back the contents of the VI > * 3.) The image triggering the problem > */ > VolatileImage vImg = null; > BufferedImage readBackBImg = new BufferedImage(25, 25, > BufferedImage.TYPE_INT_RGB); > Image tImg = new > ImageIcon(testFrame.getClass().getResource("/graybox_error.gif")).getImage(); > Graphics readBackG = readBackBImg.getGraphics(); > > do > { > if (vImg == null || > vImg.validate(testFrame.getGraphicsConfiguration()) == > VolatileImage.IMAGE_INCOMPATIBLE) > { > vImg = testFrame.createVolatileImage(25, 25); > } > > Graphics viG = vImg.getGraphics(); > viG.setColor(Color.white); > viG.fillRect(0, 0, 25, 25); > //Blit it at least two times to make sure it becomes accalerated - > This is an assumption and may break if implementation changes > viG.drawImage(tImg, 0, 0, Color.white, testFrame); > viG.drawImage(tImg, 0, 0, Color.white, testFrame); > > readBackG.drawImage(vImg, 0, 0, testFrame); > } while (vImg.contentsLost()); > > //Check wether un-initialized pixels (black) exist > for (int x = 0; x < readBackBImg.getWidth(); x++) > { > for (int y = 0; y < readBackBImg.getHeight(); y++) > { > int currPixel = readBackBImg.getRGB(x, y); > if (currPixel == Color.black.getRGB()) > { > throw new RuntimeException("Background has changed!"); > } > } > } > } > } From linuxhippy at gmail.com Fri Sep 28 20:46:25 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 28 Sep 2007 22:46:25 +0200 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <46FD5EE3.7020201@Sun.COM> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> <46FA863E.9040204@Sun.COM> <194f62550709260934o527ff85atb0ac3f88ebc177f3@mail.gmail.com> <194f62550709261224l16ea18a6t71aebb17cb7b632d@mail.gmail.com> <194f62550709261249x68ea7408yef5eeec1c9efbda6@mail.gmail.com> <46FBD987.3070305@Sun.COM> <194f62550709280342x482fb5d6g24ece43147b1637c@mail.gmail.com> <46FD2DB6.7090509@Sun.COM> <194f62550709281026q1a1bace9y4a2d5c8ead3b1ca0@mail.gmail.com> <46FD5EE3.7020201@Sun.COM> Message-ID: <194f62550709281346v60c4d25fo86e38ea82ddb58bc@mail.gmail.com> Hi Dimitri, > I'm having issues with reproducing the bug with > this or the original test. > I've tried on solaris and linux, it works fine in > both cases on all jdks I've tried. Weird. > What is your desktop bit depth? I've tried on 24bit > systems. My display also has 24bit depth, when I switch to 16bit, pixel has some ~65535 value and everything works as expected. I am using Fedora7, updated once or twice, my Laptop has an Intel GMA950, using the i810 driver. > In the debugger I see that the pixel passed to > X11SD_GetPixmapWithBg is 0x00ffffff, not 0xffffffff, > so pixel+1 != 0 . Wow thats really weird, however from the pixel-point-of-view it makes sence - 24 bytes are 1. I did some debugging, and that's the stack where I get the pixel-value from: PixelConverter$Xrgb.rgbToPixel(int, ColorModel) line: 143 SurfaceType.pixelFor(int, ColorModel) line: 434 X11SurfaceData$X11PixmapSurfaceData(SurfaceData).pixelFor(int) line: 835 X11PMBlitBgLoops.BlitBg(SurfaceData, SurfaceData, Composite, Region, Color, int, int, int, int, int, int) line: 90 BlitBg$TraceBlitBg.BlitBg(SurfaceData, SurfaceData, Composite, Region, Color, int, int, int, int, int, int) line: 211 DrawImage.blitSurfaceData(SunGraphics2D, Region, SurfaceData, SurfaceData, SurfaceType, SurfaceType, int, int, int, int, int, int, Color) line: 957 DrawImage.renderImageCopy(SunGraphics2D, Image, Color, int, int, int, int, int, int) line: 575 DrawImage.copyImage(SunGraphics2D, Image, int, int, Color) line: 71 DrawImage.copyImage(SunGraphics2D, Image, int, int, Color, ImageObserver) line: 1008 SunGraphics2D.drawImage(Image, int, int, Color, ImageObserver) line: 3053 ImageRepresentation.drawToBufImage(Graphics, ToolkitImage, int, int, Color, ImageObserver) line: 764 DrawImage.copyImage(SunGraphics2D, Image, int, int, Color, ImageObserver) line: 1015 SunGraphics2D.drawImage(Image, int, int, Color, ImageObserver) line: 3053 BgRegTest.start() line: 39 AppletViewerPanel(AppletPanel).run() line: 476 Thread.run() line: 659 Its simply returns the parameter we hand in from Color.getRGB(), my SurfaceData-Object is a sun.java2d.x11.X11SurfaceData$X11PixmapSurfaceData. Could it be a bug or no clear specification in PixelConverter$Xrgb.rgbToPixel(int, ColorModel) line: 143 be: public int rgbToPixel(int rgb, ColorModel cm) { return rgb; } public int pixelToRgb(int pixel, ColorModel cm) { return (0xff000000 | pixel); } rgbToPixel simply returns the rgb value, but pixelToRgb sets the first two bytes. The question is why doesn't it look like: public int rgbToPixel(int rgb, ColorModel cm) { return rgb & 0x00ffffff; } I am using jdk7b19, so maybe some things have changed already :-/ ------------ I wonder how the code does/should behave in the 32-bit depth case? Wouldn't be a -1 value be possible in this case? lg Clemens From Jim.A.Graham at Sun.COM Fri Sep 28 21:31:24 2007 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Fri, 28 Sep 2007 14:31:24 -0700 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <194f62550709281346v60c4d25fo86e38ea82ddb58bc@mail.gmail.com> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> <46FA863E.9040204@Sun.COM> <194f62550709260934o527ff85atb0ac3f88ebc177f3@mail.gmail.com> <194f62550709261224l16ea18a6t71aebb17cb7b632d@mail.gmail.com> <194f62550709261249x68ea7408yef5eeec1c9efbda6@mail.gmail.com> <46FBD987.3070305@Sun.COM> <194f62550709280342x482fb5d6g24ece43147b1637c@mail.gmail.com> <46FD2DB6.7090509@Sun.COM> <194f62550709281026q1a1bace9y4a2d5c8ead3b1ca0@mail.gmail.com> <46FD5EE3.7020201@Sun.COM> <194f62550709281346v60c4d25fo86e38ea82ddb58bc@mail.gmail.com> Message-ID: <0JP3004NZL3O0ZC0@fe-sfbay-10.sun.com> Perhaps the difference is that Dmitri is running on a display with Xbgr which has to decompose the argb value and recompose it into a BGR value - in the process it only moves the r, g, and b bits around. Clemens is running on an Xrgb screen and so the pixelconverter just passes on the argb value as the pixel - alpha bits and all - as he discovered. That's safe for most purposes since the alpha value should be ignored, but causes a problem with this "+1" hack. I think we ran into a case internally where the extra bits of the pixel value did cause a problem with some of the Solaris X11 drivers, but we proposed that it was a violation of X protocol and the driver was fixed. The simplest fix would probably be to just mask off the alpha in rgbToPixel and stop "playing with fire" by leaving the alpha bits set. This could also be done more specifically in the BlitBg support code (mask the pixel and +1 to see if it is set yet or not). The most robust fix is to add a boolean as originally proposed... ...jim Clemens Eisserer wrote: > Hi Dimitri, > >> I'm having issues with reproducing the bug with >> this or the original test. >> I've tried on solaris and linux, it works fine in >> both cases on all jdks I've tried. Weird. >> What is your desktop bit depth? I've tried on 24bit >> systems. > My display also has 24bit depth, when I switch to 16bit, pixel has > some ~65535 value and everything works as expected. > I am using Fedora7, updated once or twice, my Laptop has an Intel > GMA950, using the i810 driver. > >> In the debugger I see that the pixel passed to >> X11SD_GetPixmapWithBg is 0x00ffffff, not 0xffffffff, >> so pixel+1 != 0 . > Wow thats really weird, however from the pixel-point-of-view it makes > sence - 24 bytes are 1. > > I did some debugging, and that's the stack where I get the pixel-value from: > PixelConverter$Xrgb.rgbToPixel(int, ColorModel) line: 143 > SurfaceType.pixelFor(int, ColorModel) line: 434 > X11SurfaceData$X11PixmapSurfaceData(SurfaceData).pixelFor(int) line: 835 > X11PMBlitBgLoops.BlitBg(SurfaceData, SurfaceData, Composite, Region, > Color, int, int, int, int, int, int) line: 90 > BlitBg$TraceBlitBg.BlitBg(SurfaceData, SurfaceData, Composite, > Region, Color, int, int, int, int, int, int) line: 211 > DrawImage.blitSurfaceData(SunGraphics2D, Region, SurfaceData, > SurfaceData, SurfaceType, SurfaceType, int, int, int, int, int, int, > Color) line: 957 > DrawImage.renderImageCopy(SunGraphics2D, Image, Color, int, int, > int, int, int, int) line: 575 > DrawImage.copyImage(SunGraphics2D, Image, int, int, Color) line: 71 > DrawImage.copyImage(SunGraphics2D, Image, int, int, Color, > ImageObserver) line: 1008 > SunGraphics2D.drawImage(Image, int, int, Color, ImageObserver) line: 3053 > ImageRepresentation.drawToBufImage(Graphics, ToolkitImage, int, int, > Color, ImageObserver) line: 764 > DrawImage.copyImage(SunGraphics2D, Image, int, int, Color, > ImageObserver) line: 1015 > SunGraphics2D.drawImage(Image, int, int, Color, ImageObserver) line: 3053 > BgRegTest.start() line: 39 > AppletViewerPanel(AppletPanel).run() line: 476 > Thread.run() line: 659 > > Its simply returns the parameter we hand in from Color.getRGB(), my > SurfaceData-Object is a > sun.java2d.x11.X11SurfaceData$X11PixmapSurfaceData. > Could it be a bug or no clear specification in > PixelConverter$Xrgb.rgbToPixel(int, ColorModel) line: 143 be: > > public int rgbToPixel(int rgb, ColorModel cm) { > return rgb; > } > > public int pixelToRgb(int pixel, ColorModel cm) { > return (0xff000000 | pixel); > } > > rgbToPixel simply returns the rgb value, but pixelToRgb sets the > first two bytes. The question is why doesn't it look like: > public int rgbToPixel(int rgb, ColorModel cm) { > return rgb & 0x00ffffff; > } > > I am using jdk7b19, so maybe some things have changed already :-/ > > ------------ > > I wonder how the code does/should behave in the 32-bit depth case? > Wouldn't be a -1 value be possible in this case? > > lg Clemens From linuxhippy at gmail.com Fri Sep 28 21:48:39 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 28 Sep 2007 23:48:39 +0200 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <0JP3004NZL3O0ZC0@fe-sfbay-10.sun.com> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> <194f62550709261224l16ea18a6t71aebb17cb7b632d@mail.gmail.com> <194f62550709261249x68ea7408yef5eeec1c9efbda6@mail.gmail.com> <46FBD987.3070305@Sun.COM> <194f62550709280342x482fb5d6g24ece43147b1637c@mail.gmail.com> <46FD2DB6.7090509@Sun.COM> <194f62550709281026q1a1bace9y4a2d5c8ead3b1ca0@mail.gmail.com> <46FD5EE3.7020201@Sun.COM> <194f62550709281346v60c4d25fo86e38ea82ddb58bc@mail.gmail.com> <0JP3004NZL3O0ZC0@fe-sfbay-10.sun.com> Message-ID: <194f62550709281448x27b2f4b1l123ee0f23d53062f@mail.gmail.com> Hi Jim, > Perhaps the difference is that Dmitri is running on a display with Xbgr > which has to decompose the argb value and recompose it into a BGR value > - in the process it only moves the r, g, and b bits around. > > Clemens is running on an Xrgb screen and so the pixelconverter just > passes on the argb value as the pixel - alpha bits and all - as he > discovered. Thanks for the detailed analysis. > That's safe for most purposes since the alpha value should > be ignored, but causes a problem with this "+1" hack. I think we ran > into a case internally where the extra bits of the pixel value did cause > a problem with some of the Solaris X11 drivers, but we proposed that it > was a violation of X protocol and the driver was fixed. > > The simplest fix would probably be to just mask off the alpha in > rgbToPixel and stop "playing with fire" by leaving the alpha bits set. > This could also be done more specifically in the BlitBg support code > (mask the pixel and +1 to see if it is set yet or not). The most robust > fix is to add a boolean as originally proposed... I also thought about howto explain that I think the +1-hack is no good idea because such code is hard to read and could be broken unintentionally ... however on the other side it maybe uses more memory (haven't looked at the struct) so its a space/readability tradeof. Well but most time people prefer their code over others so I thought I am not in a good position to discuss this ;) What do you think about using the boolean approach and masking the pixel-value in rgbToPixel()? Could it break things or limit functionaliy? Thanks for looking into this, lg Clemens From Dmitri.Trembovetski at Sun.COM Fri Sep 28 22:03:18 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Fri, 28 Sep 2007 15:03:18 -0700 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <0JP3004NZL3O0ZC0@fe-sfbay-10.sun.com> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> <46FA863E.9040204@Sun.COM> <194f62550709260934o527ff85atb0ac3f88ebc177f3@mail.gmail.com> <194f62550709261224l16ea18a6t71aebb17cb7b632d@mail.gmail.com> <194f62550709261249x68ea7408yef5eeec1c9efbda6@mail.gmail.com> <46FBD987.3070305@Sun.COM> <194f62550709280342x482fb5d6g24ece43147b1637c@mail.gmail.com> <46FD2DB6.7090509@Sun.COM> <194f62550709281026q1a1bace9y4a2d5c8ead3b1ca0@mail.gmail.com> <46FD5EE3.7020201@Sun.COM> <194f62550709281346v60c4d25fo86e38ea82ddb58bc@mail.gmail.com> <0JP3004NZL3O0ZC0@fe-sfbay-10.sun.com> Message-ID: <46FD7A26.4050502@Sun.COM> Hi Jim, Yes, you're right: in both my tests I displayed to my sparc workstation display. When I displayed to my cygwin X server (which is Xrgb) on windows it did show the bug. Thanks, Dmitri Jim Graham wrote: > Perhaps the difference is that Dmitri is running on a display with Xbgr > which has to decompose the argb value and recompose it into a BGR value > - in the process it only moves the r, g, and b bits around. > > Clemens is running on an Xrgb screen and so the pixelconverter just > passes on the argb value as the pixel - alpha bits and all - as he > discovered. That's safe for most purposes since the alpha value should > be ignored, but causes a problem with this "+1" hack. I think we ran > into a case internally where the extra bits of the pixel value did cause > a problem with some of the Solaris X11 drivers, but we proposed that it > was a violation of X protocol and the driver was fixed. > > The simplest fix would probably be to just mask off the alpha in > rgbToPixel and stop "playing with fire" by leaving the alpha bits set. > This could also be done more specifically in the BlitBg support code > (mask the pixel and +1 to see if it is set yet or not). The most robust > fix is to add a boolean as originally proposed... > > ...jim > > Clemens Eisserer wrote: >> Hi Dimitri, >> >>> I'm having issues with reproducing the bug with >>> this or the original test. >>> I've tried on solaris and linux, it works fine in >>> both cases on all jdks I've tried. Weird. >>> What is your desktop bit depth? I've tried on 24bit >>> systems. >> My display also has 24bit depth, when I switch to 16bit, pixel has >> some ~65535 value and everything works as expected. >> I am using Fedora7, updated once or twice, my Laptop has an Intel >> GMA950, using the i810 driver. >> >>> In the debugger I see that the pixel passed to >>> X11SD_GetPixmapWithBg is 0x00ffffff, not 0xffffffff, >>> so pixel+1 != 0 . >> Wow thats really weird, however from the pixel-point-of-view it makes >> sence - 24 bytes are 1. >> >> I did some debugging, and that's the stack where I get the pixel-value >> from: >> PixelConverter$Xrgb.rgbToPixel(int, ColorModel) line: 143 >> SurfaceType.pixelFor(int, ColorModel) line: 434 >> X11SurfaceData$X11PixmapSurfaceData(SurfaceData).pixelFor(int) line: >> 835 >> X11PMBlitBgLoops.BlitBg(SurfaceData, SurfaceData, Composite, Region, >> Color, int, int, int, int, int, int) line: 90 >> BlitBg$TraceBlitBg.BlitBg(SurfaceData, SurfaceData, Composite, >> Region, Color, int, int, int, int, int, int) line: 211 >> DrawImage.blitSurfaceData(SunGraphics2D, Region, SurfaceData, >> SurfaceData, SurfaceType, SurfaceType, int, int, int, int, int, int, >> Color) line: 957 >> DrawImage.renderImageCopy(SunGraphics2D, Image, Color, int, int, >> int, int, int, int) line: 575 >> DrawImage.copyImage(SunGraphics2D, Image, int, int, Color) line: 71 >> DrawImage.copyImage(SunGraphics2D, Image, int, int, Color, >> ImageObserver) line: 1008 >> SunGraphics2D.drawImage(Image, int, int, Color, ImageObserver) line: >> 3053 >> ImageRepresentation.drawToBufImage(Graphics, ToolkitImage, int, int, >> Color, ImageObserver) line: 764 >> DrawImage.copyImage(SunGraphics2D, Image, int, int, Color, >> ImageObserver) line: 1015 >> SunGraphics2D.drawImage(Image, int, int, Color, ImageObserver) line: >> 3053 >> BgRegTest.start() line: 39 >> AppletViewerPanel(AppletPanel).run() line: 476 >> Thread.run() line: 659 >> >> Its simply returns the parameter we hand in from Color.getRGB(), my >> SurfaceData-Object is a >> sun.java2d.x11.X11SurfaceData$X11PixmapSurfaceData. >> Could it be a bug or no clear specification in >> PixelConverter$Xrgb.rgbToPixel(int, ColorModel) line: 143 be: >> >> public int rgbToPixel(int rgb, ColorModel cm) { >> return rgb; >> } >> >> public int pixelToRgb(int pixel, ColorModel cm) { >> return (0xff000000 | pixel); >> } >> >> rgbToPixel simply returns the rgb value, but pixelToRgb sets the >> first two bytes. The question is why doesn't it look like: >> public int rgbToPixel(int rgb, ColorModel cm) { >> return rgb & 0x00ffffff; >> } >> >> I am using jdk7b19, so maybe some things have changed already :-/ >> >> ------------ >> >> I wonder how the code does/should behave in the 32-bit depth case? >> Wouldn't be a -1 value be possible in this case? >> >> lg Clemens From Jim.A.Graham at Sun.COM Fri Sep 28 22:05:44 2007 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Fri, 28 Sep 2007 15:05:44 -0700 Subject: [OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor? In-Reply-To: <194f62550709281448x27b2f4b1l123ee0f23d53062f@mail.gmail.com> References: <194f62550709260809o57873be5haf65bc23067b21de@mail.gmail.com> <194f62550709261224l16ea18a6t71aebb17cb7b632d@mail.gmail.com> <194f62550709261249x68ea7408yef5eeec1c9efbda6@mail.gmail.com> <46FBD987.3070305@Sun.COM> <194f62550709280342x482fb5d6g24ece43147b1637c@mail.gmail.com> <46FD2DB6.7090509@Sun.COM> <194f62550709281026q1a1bace9y4a2d5c8ead3b1ca0@mail.gmail.com> <46FD5EE3.7020201@Sun.COM> <194f62550709281346v60c4d25fo86e38ea82ddb58bc@mail.gmail.com> <0JP3004NZL3O0ZC0@fe-sfbay-10.sun.com> <194f62550709281448x27b2f4b1l123ee0f23d53062f@mail.gmail.com> Message-ID: <0JP3000QFMOWFIB0@fe-sfbay-09.sun.com> Clemens Eisserer wrote: > however on the other side it maybe uses more memory (haven't looked at > the struct) so its a space/readability tradeof. > Well but most time people prefer their code over others so I thought > I am not in a good position to discuss this ;) I think there are other areas where we waste even more memory than that would account for - if we were worried about memory consumption at that level. If someone wanted to go on a field day at the cost of our code readability then the X11SurfaceData object could lose about 20 bytes easily. It could lose another 48 bytes just by turning the rarely used JDgaSurfaceInfo into a pointer, or perhaps make it an optional trailing part of the structure for devices that don't have DGA. > What do you think about using the boolean approach and masking the > pixel-value in rgbToPixel()? Could it break things or limit > functionaliy? I'm not sure we need to worry about masking the pixel value at this point if we use the boolean approach... ...jim From linuxhippy at gmail.com Sat Sep 29 16:25:56 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 29 Sep 2007 18:25:56 +0200 Subject: [OpenJDK 2D-Dev] How does antialiasing with the OpenGL pipeline work? Message-ID: <194f62550709290925q5387d017u3161118092c4268e@mail.gmail.com> Hello, According to Chris blog antialiasing on the OpenGL pipeline is done by generating alpha-mask-tiles, however to be honest I don't exactly understand how that works. Are those alpha-mask-tiles small images which are generated in software and migrated to vram using glTexImage2D? How are those alpha masks involved in a later stage of rendering? And where does that happen in code ... I went a bit up and down but was quite confused about how everything should play together :-/ So if I understand it right, is for a 0,0->100,100 line an alpha-mask area with the size 100px^2 needed? Thanks, lg Clemens From linuxhippy at gmail.com Sat Sep 29 21:22:28 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 29 Sep 2007 23:22:28 +0200 Subject: [OpenJDK 2D-Dev] How does antialiasing with the OpenGL pipeline work? In-Reply-To: <194f62550709290925q5387d017u3161118092c4268e@mail.gmail.com> References: <194f62550709290925q5387d017u3161118092c4268e@mail.gmail.com> Message-ID: <194f62550709291422x539070f4ld7517836fe9fdf25@mail.gmail.com> Sorry for the traffic, I just found an explanation in a bug-report. lg Clemens From roman at kennke.org Sun Sep 30 13:14:44 2007 From: roman at kennke.org (Roman Kennke) Date: Sun, 30 Sep 2007 15:14:44 +0200 Subject: [OpenJDK 2D-Dev] How does antialiasing with the OpenGL pipeline work? In-Reply-To: <194f62550709291422x539070f4ld7517836fe9fdf25@mail.gmail.com> References: <194f62550709290925q5387d017u3161118092c4268e@mail.gmail.com> <194f62550709291422x539070f4ld7517836fe9fdf25@mail.gmail.com> Message-ID: <1191158084.6021.16.camel@mercury> Hi Clemens, > Sorry for the traffic, I just found an explanation in a bug-report. Hey come on! I'd like to know the answer too. Give us a pointer to this bug report! ;-) Cheers, Roman -- http://kennke.org/blog/