From linuxhippy at gmail.com Mon Oct 1 06:14:02 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 1 Oct 2007 08:14:02 +0200 Subject: [OpenJDK 2D-Dev] How does antialiasing with the OpenGL pipeline work? In-Reply-To: <1191158084.6021.16.camel@mercury> References: <194f62550709290925q5387d017u3161118092c4268e@mail.gmail.com> <194f62550709291422x539070f4ld7517836fe9fdf25@mail.gmail.com> <1191158084.6021.16.camel@mercury> Message-ID: <194f62550709302314r2262e4fduac78fc3f7019dac3@mail.gmail.com> Hi Roman, > Hey come on! I'd like to know the answer too. Give us a pointer to this > bug report! ;-) Of course not ... here it is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6529101 ;) Although I don't understand / it does not mention all the details it seems they let produce those alpha-masks by doctus and indeed upload those alpha-masks to vram which seems to cause performance-problems for simple operations covering large areas. What I still don't know is how these alpha-masks look in detail and wether the "normal" rendering is done? I guess the mask is used as mask and then "painted" with color ;) Btw. I read in your blog that you've done a rasterizer - whats the state of it, or the renderer implemented by Jim? I am just looking for a simple one to lern/"reserach" a bit in this topic. Thanks, lg Clemens From roman at kennke.org Mon Oct 1 07:14:57 2007 From: roman at kennke.org (Roman Kennke) Date: Mon, 01 Oct 2007 09:14:57 +0200 Subject: [OpenJDK 2D-Dev] How does antialiasing with the OpenGL pipeline work? In-Reply-To: <194f62550709302314r2262e4fduac78fc3f7019dac3@mail.gmail.com> References: <194f62550709290925q5387d017u3161118092c4268e@mail.gmail.com> <194f62550709291422x539070f4ld7517836fe9fdf25@mail.gmail.com> <1191158084.6021.16.camel@mercury> <194f62550709302314r2262e4fduac78fc3f7019dac3@mail.gmail.com> Message-ID: <1191222897.6088.13.camel@mercury> Hi Clemens, > > Hey come on! I'd like to know the answer too. Give us a pointer to this > > bug report! ;-) > Of course not ... here it is: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6529101 ;) thanks alot! > Although I don't understand / it does not mention all the details it > seems they let produce those alpha-masks by doctus and indeed upload > those alpha-masks to vram which seems to cause performance-problems > for simple operations covering large areas. Yeah, your example of a diagonal line is kindof a worst case. A simple shape with few pixels which span a big rectangular region. > What I still don't know is how these alpha-masks look in detail and > wether the "normal" rendering is done? I guess the mask is used as > mask and then "painted" with color ;) AFAICS, the mask is a simple array (tip: have a look at the 'interface' class sun.java2d.pipe.RenderingEngine and especially the class AATileGenerator). I haven't looked at the details of OpenGL, but from what I know from other backends, the actual rendering is done by sending the alpha mask together with the shape coordinates and a solid color. When the paint is set to something more complex, then a texture has to be send too. > Btw. I read in your blog that you've done a rasterizer - whats the > state of it, or the renderer implemented by Jim? I am just looking for > a simple one to lern/"reserach" a bit in this topic. My rasterizer hasn't moved forward since my proposal here on the list. I'm too busy with work, family and stuff. AFAIK, Jim Graham has hacked up another rasterizer (I hope I'm not telling secrets here. Jim: you really should discuss these things in public...) derived from Pisces. I think it will be included in one of the next release shots. If you bother Jim, he might send you the code before, ideally to this list so everybody could have a look. Cheers, Roman -- http://kennke.org/blog/ From Jim.A.Graham at Sun.COM Mon Oct 1 19:20:00 2007 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Mon, 01 Oct 2007 12:20:00 -0700 Subject: [OpenJDK 2D-Dev] How does antialiasing with the OpenGL pipeline work? In-Reply-To: <194f62550709302314r2262e4fduac78fc3f7019dac3@mail.gmail.com> References: <194f62550709290925q5387d017u3161118092c4268e@mail.gmail.com> <194f62550709291422x539070f4ld7517836fe9fdf25@mail.gmail.com> <1191158084.6021.16.camel@mercury> <194f62550709302314r2262e4fduac78fc3f7019dac3@mail.gmail.com> Message-ID: <0JP800BMQYYDY940@fe-sfbay-09.sun.com> One thing the bug report doesn't seem to mention is that the tiles are 32x32 (it implies it by talking about the 1024 values being copied), and that there is a function which quickly tells you whether a tile is all 0s or all 1s so the renderer can either skip or do quicker fills of regions that are all inside or all outside the path. The sun.java2d.pipe.AATileGenerator interface currently in the public sources defines the methods in that workflow and shows a sample of how they work. You can see it being used in a real world setting in the AAShapePipe class in the same package... ...jim Clemens Eisserer wrote: > Hi Roman, > >> Hey come on! I'd like to know the answer too. Give us a pointer to this >> bug report! ;-) > Of course not ... here it is: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6529101 ;) > > Although I don't understand / it does not mention all the details it > seems they let produce those alpha-masks by doctus and indeed upload > those alpha-masks to vram which seems to cause performance-problems > for simple operations covering large areas. > What I still don't know is how these alpha-masks look in detail and > wether the "normal" rendering is done? I guess the mask is used as > mask and then "painted" with color ;) > > Btw. I read in your blog that you've done a rasterizer - whats the > state of it, or the renderer implemented by Jim? I am just looking for > a simple one to lern/"reserach" a bit in this topic. > > Thanks, lg Clemens From linuxhippy at gmail.com Mon Oct 1 20:22:22 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 1 Oct 2007 22:22:22 +0200 Subject: [OpenJDK 2D-Dev] How does antialiasing with the OpenGL pipeline work? In-Reply-To: <0JP800BMQYYDY940@fe-sfbay-09.sun.com> References: <194f62550709290925q5387d017u3161118092c4268e@mail.gmail.com> <194f62550709291422x539070f4ld7517836fe9fdf25@mail.gmail.com> <1191158084.6021.16.camel@mercury> <194f62550709302314r2262e4fduac78fc3f7019dac3@mail.gmail.com> <0JP800BMQYYDY940@fe-sfbay-09.sun.com> Message-ID: <194f62550710011322wcaabf0bkb0ef61d953f27396@mail.gmail.com> Hi again, The reason why I asked is because the idea of a rasterizer is in my head which is written in GLSL. Because the whole rasterization-process is pixel-for-pixel (or in the case of AA, a pixel many times) a fragment shader seems somehow cool. Of course I know that the shader would run extremly slow (compared to other shader-scripts usually used in 3d games), and that maybe even fragment-shader-3.0 is needed for all the conditions - but maybe a pre-digested format could be sent to the GPU which minimizes the amount of corner-cases and complex logic stuff. A great benefit of such a shader would be batch-abilitiy, so if e.g. many lines are drawn with solid colors, all could be done in one shader-run. So only one upload would be needed for many small operation. Even if it would never reach production quality or high performance, it somehow fascinates me ;) lg Clemens 2007/10/1, Jim Graham : > One thing the bug report doesn't seem to mention is that the tiles are > 32x32 (it implies it by talking about the 1024 values being copied), and > that there is a function which quickly tells you whether a tile is all > 0s or all 1s so the renderer can either skip or do quicker fills of > regions that are all inside or all outside the path. > > The sun.java2d.pipe.AATileGenerator interface currently in the public > sources defines the methods in that workflow and shows a sample of how > they work. You can see it being used in a real world setting in the > AAShapePipe class in the same package... > > ...jim > > Clemens Eisserer wrote: > > Hi Roman, > > > >> Hey come on! I'd like to know the answer too. Give us a pointer to this > >> bug report! ;-) > > Of course not ... here it is: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6529101 ;) > > > > Although I don't understand / it does not mention all the details it > > seems they let produce those alpha-masks by doctus and indeed upload > > those alpha-masks to vram which seems to cause performance-problems > > for simple operations covering large areas. > > What I still don't know is how these alpha-masks look in detail and > > wether the "normal" rendering is done? I guess the mask is used as > > mask and then "painted" with color ;) > > > > Btw. I read in your blog that you've done a rasterizer - whats the > > state of it, or the renderer implemented by Jim? I am just looking for > > a simple one to lern/"reserach" a bit in this topic. > > > > Thanks, lg Clemens > From Dmitri.Trembovetski at Sun.COM Mon Oct 1 22:52:29 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Mon, 01 Oct 2007 15:52:29 -0700 Subject: [OpenJDK 2D-Dev] Fix integrated [Was Re: 6603887: Where are transparent areas filled with bgColor?] In-Reply-To: <0JP3000QFMOWFIB0@fe-sfbay-09.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> <194f62550709281448x27b2f4b1l123ee0f23d53062f@mail.gmail.com> <0JP3000QFMOWFIB0@fe-sfbay-09.sun.com> Message-ID: <47017A2D.8080301@Sun.COM> Just an update on this bug: we've integrated Clemens' suggested fix into the team workspace. It should appear in the next build (b22). Thanks to Clemens for the fix and for bearing with our internal process =) Thanks, Dmitri Jim Graham wrote: > 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 Phil.Race at Sun.COM Mon Oct 1 23:16:46 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Mon, 01 Oct 2007 16:16:46 -0700 Subject: [OpenJDK 2D-Dev] Remove warnings In-Reply-To: References: <1190752995.29921.8.camel@mercury> <46FC021D.4060702@sun.com> Message-ID: <47017FDE.90007@sun.com> Looks like the netbeans jackpot module can also be used for this : http://jackpot.netbeans.org/docs/transformer-module-tutorial.html#QueryDescription I don't think it matters if its an IDE as long as you can just press the "do it" button a small number of times. -phil. Ismael Juma wrote: > 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 pdoubleya at gmail.com Tue Oct 2 05:26:46 2007 From: pdoubleya at gmail.com (Patrick Wright) Date: Tue, 2 Oct 2007 07:26:46 +0200 Subject: [OpenJDK 2D-Dev] Remove warnings In-Reply-To: <47017FDE.90007@sun.com> References: <1190752995.29921.8.camel@mercury> <46FC021D.4060702@sun.com> <47017FDE.90007@sun.com> Message-ID: <64efa1ba0710012226s4adec46br422d0171c65f455d@mail.gmail.com> FWIW, using Jackpot to clean up these sorts of simple problems seems like a good task to have around for people who want to get started sending in patches. Patrick From roman at kennke.org Wed Oct 3 22:33:44 2007 From: roman at kennke.org (Roman Kennke) Date: Thu, 04 Oct 2007 00:33:44 +0200 Subject: [OpenJDK 2D-Dev] Remove warnings in sun.java2d Message-ID: <1191450824.1255.25.camel@mercury> I looked through the classes in sun.java2d and removed most warnings there. That is, unused imports, @Override annotations, local variables hiding fields, static field access through an instance, redundant casts and maybe something else I forgot. Find the patch attached. /Roman -- http://kennke.org/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-java2d-warnings2.diff Type: text/x-patch Size: 43583 bytes Desc: not available URL: From Jim.A.Graham at Sun.COM Thu Oct 4 00:29:31 2007 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Wed, 03 Oct 2007 17:29:31 -0700 Subject: [OpenJDK 2D-Dev] Open Source rasterizer Message-ID: <0JPD0093H2OJMI30@fe-sfbay-10.sun.com> As Roman mentioned earlier, I've culled together some code from another Java project into a replacement for the encumbered Ductus renderer in the production JDK. This rasterizer is built from all of our own code so we can release it as part of the Open JDK project. Unfortunately, it isn't as fast as the existing Ductus binary plugs so some work will be needed to improve its speed, but it covers the entire API that we used to rely on Ductus for so we've removed the binary plugs from the Open Source version. Here are some known issues with the new rasterizer that need to be addressed: - Performance, performance, performance - It uses fixed point without much overflow detection/handling - It does not honor the STROKE_CONTROL hints so thin lines are vague In terms of performance, someone who is good with a code analyzer could have a field day, but here are some ideas that would be reasonably easy to investigate to see if they make a noticeable improvement in the performance: - reusing the Renderer and associated objects vs. recreating them - A better storage format for the PiscesCache for generating tiles - Tighter integration between the pixelization code and the cache - use floats in the line widening which should go faster on desktops I'm attaching a zip file of the sources for a sneak peek. These sources should appear in the public repository in a few days (just barely beating the temporary freeze for the Mercurial transition). I'd recommend anyone interested in playing with this code to join the "Graphics-Rasterizer-Dev" list on openjdk: http://mail.openjdk.java.net/mailman/listinfo/graphics-rasterizer-dev ...jim -------------- next part -------------- A non-text attachment was scrubbed... Name: pisces.zip Type: application/zip Size: 32915 bytes Desc: not available URL: From linuxhippy at gmail.com Thu Oct 4 10:02:09 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 4 Oct 2007 12:02:09 +0200 Subject: [OpenJDK 2D-Dev] How does antialiasing with the OpenGL pipeline work? In-Reply-To: <194f62550710011322wcaabf0bkb0ef61d953f27396@mail.gmail.com> References: <194f62550709290925q5387d017u3161118092c4268e@mail.gmail.com> <194f62550709291422x539070f4ld7517836fe9fdf25@mail.gmail.com> <1191158084.6021.16.camel@mercury> <194f62550709302314r2262e4fduac78fc3f7019dac3@mail.gmail.com> <0JP800BMQYYDY940@fe-sfbay-09.sun.com> <194f62550710011322wcaabf0bkb0ef61d953f27396@mail.gmail.com> Message-ID: <194f62550710040302g77dd9287mdbeadd1b39f2da29@mail.gmail.com> Hi, Ok, after looking at the open rasterizer's source I pretty much throw away the idea of implementing it as shader ;) However one thing which still seems interesting to me is to do scanline-rendering via a shader. A simple opcode-protocoll could be uploaded to the texture which is read and executed by a simple shader. As far as I've seen ProcessPath.c/h do the conversation between paths and scanlines (btw. why is there a native and a java version). Wouldn't it be possible to redirect AA rendering through the non-antialiased path, somehow get the coverage values of the scanline endpoints (maybe using fp left/right coordinates), upload it to a texture and let the shader do all the pixel-calculation stuff? Maybe even some batching could be performed, uploading several scanlines one after another of no state-changes occur. I'll do some experiments on my Geforce-FX5200 to see how the shader-part would perform but I guess if it works in this card fast ... everything else should do it too ;) Another thing which makes me curious are the results of the AA'd line testcase mentioned in the bug-report: 1100.x11: 544.5535714 (var=1.61%) (100.0%) 1100.base: 376.7876787 (var=1.29%) (69.19%) 1100.align: 375.4134509 (var=1.48%) (68.94%) 1100.notex: 607.7712609 (var=1.58%) (111.61%) So removing the texture-upload "only" increases performance relative to x11 by about 40%. So I wonder where the other time is spent? How large do you estimate the part consumed by doctus to create the mask-tiles? Sorry for all the traffic ... Thanks, lg Clemens From Dmitri.Trembovetski at Sun.COM Thu Oct 4 16:23:54 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 04 Oct 2007 09:23:54 -0700 Subject: [OpenJDK 2D-Dev] Remove warnings in sun.java2d In-Reply-To: <1191450824.1255.25.camel@mercury> References: <1191450824.1255.25.camel@mercury> Message-ID: <4705139A.9000303@Sun.COM> Hi Roman, thanks for the patch. We're currently in a somewhat of a freeze because of the move to Mercurial, so we'll probably integrate the patch after that's done. Thanks, Dmitri Roman Kennke wrote: > I looked through the classes in sun.java2d and removed most warnings > there. That is, unused imports, @Override annotations, local variables > hiding fields, static field access through an instance, redundant casts > and maybe something else I forgot. > > Find the patch attached. > > /Roman > > From Phil.Race at Sun.COM Thu Oct 4 19:03:35 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 04 Oct 2007 12:03:35 -0700 Subject: [OpenJDK 2D-Dev] Imaging and graphics job opening at Sun. Message-ID: <47053907.3060801@sun.com> Hello all, Want to get paid for developing free software? The Java 2D graphics and JAI imaging team here at Sun have an immediate opening for an engineer to join us to work on imaging and graphics for Java SE. The full details of the job are posted at the link below where you may also submit your resum? to apply. http://www.sun.com/corp_emp/search.cgi?funcs=&loc=&keyword=555887&x=&y= -Phil Race, Java 2D. From roman at kennke.org Thu Oct 4 19:29:16 2007 From: roman at kennke.org (Roman Kennke) Date: Thu, 04 Oct 2007 21:29:16 +0200 Subject: [OpenJDK 2D-Dev] Remove warnings in sun.java2d In-Reply-To: <4705139A.9000303@Sun.COM> References: <1191450824.1255.25.camel@mercury> <4705139A.9000303@Sun.COM> Message-ID: <1191526156.6182.10.camel@mercury> Hi Dmitri, > thanks for the patch. > > We're currently in a somewhat of a freeze because of > the move to Mercurial, so we'll probably integrate the patch > after that's done. Cool, thank you. I'll wait with more patches then until Mercurial is done. Will we get read-access to the j2d group workspace then? /Roman -- http://kennke.org/blog/ From Dmitri.Trembovetski at Sun.COM Thu Oct 4 19:43:30 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 04 Oct 2007 12:43:30 -0700 Subject: [OpenJDK 2D-Dev] Remove warnings in sun.java2d In-Reply-To: <1191526156.6182.10.camel@mercury> References: <1191450824.1255.25.camel@mercury> <4705139A.9000303@Sun.COM> <1191526156.6182.10.camel@mercury> Message-ID: <47054262.3070609@Sun.COM> Hi Roman, Roman Kennke wrote: > Hi Dmitri, > >> thanks for the patch. >> >> We're currently in a somewhat of a freeze because of >> the move to Mercurial, so we'll probably integrate the patch >> after that's done. > > Cool, thank you. I'll wait with more patches then until Mercurial is > done. Will we get read-access to the j2d group workspace then? I'd have to defer to Mark for this. Mark, when will the external access infrastructure be ready? Thanks, Dmitri From mr at sun.com Thu Oct 4 19:47:31 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 04 Oct 2007 12:47:31 -0700 Subject: [OpenJDK 2D-Dev] Remove warnings in sun.java2d In-Reply-To: dmitri.trembovetski@sun.com; Thu, 04 Oct 2007 12:43:30 PDT; <47054262.3070609@Sun.COM> Message-ID: <20071004194731.CED3A62F8@eggemoggin.niobe.net> > Date: Thu, 04 Oct 2007 12:43:30 -0700 > From: dmitri.trembovetski at sun.com > Mark, when will the external access infrastructure be ready? If not at the time of the internal Mercurial cutover around the end of this month, then very shortly thereafter. - Mark