From roman.kennke at aicas.com Fri Jun 8 14:19:49 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Fri, 08 Jun 2007 23:19:49 +0200 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <46561F45.60709@sun.com> References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> Message-ID: <1181337589.5898.39.camel@mercury> Hi there, > Thanks for this. Jim Graham is the best person to comment > on this but he's on vacation until next week some time. I'm also back from my honeymoon vacation now. Has anybody had the time to review my rasterizer yet? /Roman -- Dipl.-Inf. 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 Jim.A.Graham at Sun.COM Mon Jun 11 14:43:44 2007 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Mon, 11 Jun 2007 14:43:44 -0700 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <1181337589.5898.39.camel@mercury> References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> Message-ID: <0JJH00C70QX40530@fe-sfbay-09.sun.com> Hi Roman, The status on the pluggability API is that it is now completed and in our 2D integration workspaces waiting to go through the testing and promotion queues. The best current estimate as to when all of that process will be done is that it will probably appear on the OpenJDK project site the end of next week. In the meantime, I'm attaching a zip file of the javadoc output on the new classes so you can start looking at the API. Keep in mind that I mentioned earlier that this was not intended to be the eventual final API that allows alternate implementations to play nicely on a level playing field in the long run, but more of a stopgap temporary milestone on the road to producing an all-open JDK. To that end, I identified basically just 3 places where our common code depended on the Ductus library and produced a very basic plugin interface containing 3 methods for those cases. The plugin has been tested with a NOP stub, but not an alternate implementation. From here I definitely want to start opening up the discussion for some more extensive work to plug in (or even replace) new renderers. I'd like our goal to be a fully open implementation that performs much better than the current collection of diverse rasterizers and not have separate production vs. open implementations moving forward... ...jim Roman Kennke wrote: > Hi there, > >> Thanks for this. Jim Graham is the best person to comment >> on this but he's on vacation until next week some time. > > I'm also back from my honeymoon vacation now. Has anybody had the time > to review my rasterizer yet? > > /Roman > -------------- next part -------------- A non-text attachment was scrubbed... Name: RenderingEngine_docs.zip Type: application/zip Size: 34365 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/attachments/20070611/082eced6/attachment.zip From Dmitri.Trembovetski at Sun.COM Tue Jun 12 10:10:42 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Tue, 12 Jun 2007 10:10:42 -0700 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <1181587836.10925.15.camel@mercury> References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <466D8A79.4070909@Sun.COM> <1181587836.10925.15.camel@mercury> Message-ID: <466ED392.9060709@Sun.COM> Hi Roman, getting back on the list. Roman Kennke wrote: > Hi Dmitri, > > first of all, you should continue discussion on the mailing list IMO. It > doesn't leave a good impression against 'the community' when half of the > discussions are held privately. I won't CC the list now though, because > you might have had a reason not to do this in the first place. If you > feel like we could discuss that openly, then please CC the list again > when answering. Just to clarify: whenever possible legal questions are involved, I tend to be a bit hesitant to involve large audiences, which was the reason I went off the list. However, in this case it will be useful for everybody else to understand the restrictions under which we currently operate. >> I think there are still legal issues preventing >> us looking at this code =( > > Unbelievable. But oh well... Why exactly can't you *look* at the code. > Because it's not submitted via the SCA? I mean, it's free, open source > software after all. Are you not allowed to look at any code except Sun > copyrighted? Yes, our understanding is that we can not look at your code until you share the copyright (and we can be reasonably sure that you own that copyright) - both of these conditions are not yet satisfied here - the second one because you mentioned about the possibility of your employer's involvement, so we wanted to clarify that first. I don't think it's Sun only policy, pretty much any company has it. It is easy to become tainted by looking at other's people code. The fact that the code is open-source doesn't matter, since it's a question of copyright. >> This particular piece got the attention: >> > and will do the copyright grantback procedure and sign the SCA (I think >> > my employer (aicas) already did so for me even) to make this code >> >> You have to sign the SCA yourself, your company >> can't do that for you - that's what the lawyers here >> say anyway. Also, it is not clear from your message >> if your company holds the copyright for this code >> (i.e. Sun holds copyright for all job-related code >> I write while working for Sun, so I can't say that >> I own the copyright even if I wrote all the code >> myself) > > I have to ask my boss(es). I believe that I am the copyright holder of > that code because I didn't write it in my work time, and not for the > purpuse of using it in the JamaicaVM, and I submitted this particular > piece of code under my personal FSF copyright assignment. But it is no > problem for me to sign the SCA myself too. However, as I pointed out, > I'd first hear your opinion if that code is useful for you before I > start the copyright-grantback dance with the FSF. I hope that doesn't > cause a deadlock (if it really does, I might rethink, but it is my hope > that Sun opens up a little more in this respect). I'm afraid that we won't be able to look at it until you sign the SCA. >> The good news is that Jim integrated his AA renderer >> interface, which you use for your rasterizer. >> I'll ask Jim again to at least publish the javadocs >> now on the list, because it will take a couple >> of weeks for the fix to get into the promoted build, >> which you would be able to access. > > Javadocs would be very helpful for a start. Jim has sent the javadocs. He mentioned that he might make one change (change AATileGenerator to be an interface instead of an abstract class - we've missed that during the review) before it goes out. >> I hope we'll make it easier for you and others to work >> directly with our 2D workspace instead of waiting for >> the fix to propagate to the main j2se workspace. > > Yeah, this seems like the biggest complaint right now. It is not really > possible for the community (e.g. me) to help out with code like this > when development is basically done behind closed doors. I am quite sure > that I could help out with both the rasterizer as well as with the > fonts, but it doesn't make much sense (and isn't very motivating) to > develop against code that is a couple of days/weeks old. I agree that the current situation is totally unacceptable. It is also unfortunate that you do not have access to our code review system - although this is relatively easy to fix - we can include you as a reviewer in relevant code changes (the system is email and web-based). We'll have to send you the actual diffs directly, though, as you won't be able to access the web interface. > I think it would make sense to at least provide read access to the real > group workspace (if you're paranoid then maybe only to group members, > but then comes the question, how can anybody become a group member?). I'll see if we could arrange that. I believe that it is our intention anyway - once we move to Mercurial each "group" will have their read/write mercurial workspace and members of the group will have read and in some cases write access. But at this point even a read-only svn workspace would help. Thank you, Dmitri From Tom.Marble at Sun.COM Tue Jun 12 10:31:56 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Tue, 12 Jun 2007 12:31:56 -0500 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <466ED392.9060709@Sun.COM> References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <466D8A79.4070909@Sun.COM> <1181587836.10925.15.camel@mercury> <466ED392.9060709@Sun.COM> Message-ID: <466ED88C.7020302@sun.com> Dmitri Trembovetski wrote: > It is also unfortunate that you do not have access to our > code review system - although this is relatively easy > to fix - we can include you as a reviewer in relevant > code changes (the system is email and web-based). > > We'll have to send you the actual diffs directly, though, > as you won't be able to access the web interface. Why couldn't we make a little tarball of the webrev directory and publish that on a mailing list? Regards, --Tom From roman.kennke at aicas.com Tue Jun 12 10:32:51 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 12 Jun 2007 19:32:51 +0200 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <466ED392.9060709@Sun.COM> References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <466D8A79.4070909@Sun.COM> <1181587836.10925.15.camel@mercury> <466ED392.9060709@Sun.COM> Message-ID: <1181669571.6063.38.camel@mercury> Hi, > getting back on the list. Good! > >> I think there are still legal issues preventing > >> us looking at this code =( > > > > Unbelievable. But oh well... Why exactly can't you *look* at the code. > > Because it's not submitted via the SCA? I mean, it's free, open source > > software after all. Are you not allowed to look at any code except Sun > > copyrighted? > > Yes, our understanding is that we can not look at your code until > you share the copyright (and we can be reasonably sure that you > own that copyright) - both of these conditions are not yet > satisfied here - the second one because you mentioned about > the possibility of your employer's involvement, so we wanted > to clarify that first. I will send in my signed SCA the next couple of days, and at the same time find out who is the actual copyright owner (me, or aicas - my employer -, aicas already signed the SCA even). The remaining issue is that the copyright is assigned to the FSF. I have hoped that you would review my code before I start the copyright grantback dance for that code. I am currently discussing this issue with Tom Marble and Mark Wielaard. > >> I hope we'll make it easier for you and others to work > >> directly with our 2D workspace instead of waiting for > >> the fix to propagate to the main j2se workspace. > > > > Yeah, this seems like the biggest complaint right now. It is not > really > > possible for the community (e.g. me) to help out with code like this > > when development is basically done behind closed doors. I am quite > sure > > that I could help out with both the rasterizer as well as with the > > fonts, but it doesn't make much sense (and isn't very motivating) to > > develop against code that is a couple of days/weeks old. > > I agree that the current situation is totally unacceptable. > > It is also unfortunate that you do not have access to our > code review system - although this is relatively easy > to fix - we can include you as a reviewer in relevant > code changes (the system is email and web-based). That'd be great. > We'll have to send you the actual diffs directly, though, > as you won't be able to access the web interface. I prefer that anyway, as this is how it works in other projects I'm involved in. > > I think it would make sense to at least provide read access to the real > > group workspace (if you're paranoid then maybe only to group members, > > but then comes the question, how can anybody become a group member?). > > I'll see if we could arrange that. I believe that it is our > intention anyway - once we move to Mercurial each "group" will have > their read/write mercurial workspace and members of the group > will have read and in some cases write access. > > But at this point even a read-only svn workspace would help. Agreed. Kind regards, 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 Phil.Race at Sun.COM Tue Jun 12 10:39:43 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 12 Jun 2007 10:39:43 -0700 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <466ED88C.7020302@sun.com> References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <466D8A79.4070909@Sun.COM> <1181587836.10925.15.camel@mercury> <466ED392.9060709@Sun.COM> <466ED88C.7020302@sun.com> Message-ID: <466EDA5F.3070501@sun.com> Note that the webrev includes some of the closed sources too : Javadocs Cdiffs Sdiffs Old New src/closed/share/classes/sun/dc/pr/PathStroker.java Javadocs Cdiffs Sdiffs Old New src/closed/share/native/sun/dc/pr/PathStroker.c I am quite sure they would need to be [manually] elided. -phil. Tom Marble wrote: > Dmitri Trembovetski wrote: >> It is also unfortunate that you do not have access to our >> code review system - although this is relatively easy >> to fix - we can include you as a reviewer in relevant >> code changes (the system is email and web-based). >> >> We'll have to send you the actual diffs directly, though, >> as you won't be able to access the web interface. > > Why couldn't we make a little tarball of the webrev directory > and publish that on a mailing list? > > Regards, > > --Tom From roman.kennke at aicas.com Tue Jun 12 10:42:59 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 12 Jun 2007 19:42:59 +0200 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <0JJH00C70QX40530@fe-sfbay-09.sun.com> References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <0JJH00C70QX40530@fe-sfbay-09.sun.com> Message-ID: <1181670179.11799.4.camel@mercury> Hi Jim, > The status on the pluggability API is that it is now completed and in > our 2D integration workspaces waiting to go through the testing and > promotion queues. The best current estimate as to when all of that > process will be done is that it will probably appear on the OpenJDK > project site the end of next week. > > In the meantime, I'm attaching a zip file of the javadoc output on the > new classes so you can start looking at the API. Great! I'll have a look at how to fit my rasterizer to this. > Keep in mind that I > mentioned earlier that this was not intended to be the eventual final > API that allows alternate implementations to play nicely on a level > playing field in the long run, but more of a stopgap temporary milestone > on the road to producing an all-open JDK. That's not a problem, actually I think it makes a lot of sense to publish work-in-progress stuff rather than finished pieces of code, because this way you get early review and testing. Working with the community means including everybody in the process, not including everybody in the finished product ;-) > To that end, I identified > basically just 3 places where our common code depended on the Ductus > library and produced a very basic plugin interface containing 3 methods > for those cases. The plugin has been tested with a NOP stub, but not an > alternate implementation. > > From here I definitely want to start opening up the discussion for some > more extensive work to plug in (or even replace) new renderers. I'd > like our goal to be a fully open implementation that performs much > better than the current collection of diverse rasterizers and not have > separate production vs. open implementations moving forward... I'd propose to start with the 'fully open' aspect and move on to the 'performs much better' aspect then ;-) The next logical step from my POV would be: For me, - to figure out the copyright thing and start the grantback procedure with the FSF. - the see how the rasterizer could fit with the documented interface For you, - to figure out the legal issues and hopefully review my code when my SCA is on file and the grantback procedure started. - implement and/or publish tests against the documented interface together with the ductus library, to be able to test and compare alternate implementations for correctness, precision and performance. Regards, 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 Phil.Race at Sun.COM Tue Jun 12 10:52:14 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 12 Jun 2007 10:52:14 -0700 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <1181669571.6063.38.camel@mercury> References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <466D8A79.4070909@Sun.COM> <1181587836.10925.15.camel@mercury> <466ED392.9060709@Sun.COM> <1181669571.6063.38.camel@mercury> Message-ID: <466EDD4E.3080306@sun.com> Roman Kennke wrote: > Hi, > > I will send in my signed SCA the next couple of days, and at the same > time find out who is the actual copyright owner (me, or aicas - my > employer -, aicas already signed the SCA even). The remaining issue is > that the copyright is assigned to the FSF. I have hoped that you would > review my code before I start the copyright grantback dance for that > code. I am currently discussing this issue with Tom Marble and Mark > Wielaard. What is the copyright grantback dance? If you wrote the code what possible issue can there be? No one should be able to take away your rights to your code. Frankly a lot of this is still learning for us. We've had less info internally on this contribution process etc etc than has been communicated externally. And when legal etc say we can only look at contributions made under an SCA, we pretty much have to do what they say. Perhaps there are other rules which allow it but I don't know that, and as an individual engineer I don't want to be making calls myself. I'd probably get me or Sun in trouble if I did. >> >> It is also unfortunate that you do not have access to our >> code review system - although this is relatively easy >> to fix - we can include you as a reviewer in relevant >> code changes (the system is email and web-based). The rush (it was a close thing even if that's not apparent) to get the source launched for JavaOne meant that we are nowhere near on the infrastructure to support it etc. -phil. From roman.kennke at aicas.com Tue Jun 12 11:17:20 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 12 Jun 2007 20:17:20 +0200 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <466EDD4E.3080306@sun.com> References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <466D8A79.4070909@Sun.COM> <1181587836.10925.15.camel@mercury> <466ED392.9060709@Sun.COM> <1181669571.6063.38.camel@mercury> <466EDD4E.3080306@sun.com> Message-ID: <1181672240.11799.9.camel@mercury> Hi, > > I will send in my signed SCA the next couple of days, and at the same > > time find out who is the actual copyright owner (me, or aicas - my > > employer -, aicas already signed the SCA even). The remaining issue is > > that the copyright is assigned to the FSF. I have hoped that you would > > review my code before I start the copyright grantback dance for that > > code. I am currently discussing this issue with Tom Marble and Mark > > Wielaard. > > What is the copyright grantback dance? If you wrote the code what > possible issue can there be? No one should be able to take away > your rights to your code. > Frankly a lot of this is still learning for us. When I wrote this code for GNU Classpath, I assigned copyright to the FSF, just like OpenJDK contributions are copyright-assigned to Sun. With the difference that the SCA is automatically granting the contributor all rights to the code, while with the FSF CA I need to go through a copyright grantback procedure, in order to make sure that all the code I 'want back' was originally written by myself. > We've had less info internally on this contribution > process etc etc than has been communicated externally. > > And when legal etc say we can only look at contributions made under > an SCA, we pretty much have to do what they say. Perhaps > there are other rules which allow it but I don't know that, > and as an individual engineer I don't want to be making calls myself. > I'd probably get me or Sun in trouble if I did. I understand this very much. > >> It is also unfortunate that you do not have access to our > >> code review system - although this is relatively easy > >> to fix - we can include you as a reviewer in relevant > >> code changes (the system is email and web-based). > > > The rush (it was a close thing even if that's not apparent) > to get the source launched for JavaOne meant that we are nowhere > near on the infrastructure to support it etc. This is understood too. No worries :-) Kind regards, 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 Phil.Race at Sun.COM Tue Jun 12 11:34:15 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 12 Jun 2007 11:34:15 -0700 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <1181672240.11799.9.camel@mercury> References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <466D8A79.4070909@Sun.COM> <1181587836.10925.15.camel@mercury> <466ED392.9060709@Sun.COM> <1181669571.6063.38.camel@mercury> <466EDD4E.3080306@sun.com> <1181672240.11799.9.camel@mercury> Message-ID: <466EE727.2010600@sun.com> Roman Kennke wrote: > When I wrote this code for GNU Classpath, I assigned copyright to the > FSF, just like OpenJDK contributions are copyright-assigned to Sun. With > the difference that the SCA is automatically granting the contributor > all rights to the code, while with the FSF CA I need to go through a > copyright grantback procedure, in order to make sure that all the code I > 'want back' was originally written by myself. > So I've heard mutterings that there's discussions with FSF to make it easier for OpenJDK to take code from classpath. I hadn't really understood how that could work, and what it meant, but now I think it does not mean *any* code from classpath, but rather something that makes this 'dance' have less moves? ie it will not mean any code from classpath, rather just specific code that the original author wants to use under grantback. Is that about right? -Phil. From roman.kennke at aicas.com Tue Jun 12 11:49:17 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 12 Jun 2007 20:49:17 +0200 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <466EE727.2010600@sun.com> References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <466D8A79.4070909@Sun.COM> <1181587836.10925.15.camel@mercury> <466ED392.9060709@Sun.COM> <1181669571.6063.38.camel@mercury> <466EDD4E.3080306@sun.com> <1181672240.11799.9.camel@mercury> <466EE727.2010600@sun.com> Message-ID: <1181674157.11799.13.camel@mercury> Hi Phil, > > When I wrote this code for GNU Classpath, I assigned copyright to the > > FSF, just like OpenJDK contributions are copyright-assigned to Sun. With > > the difference that the SCA is automatically granting the contributor > > all rights to the code, while with the FSF CA I need to go through a > > copyright grantback procedure, in order to make sure that all the code I > > 'want back' was originally written by myself. > > > > So I've heard mutterings that there's discussions with FSF to make > it easier for OpenJDK to take code from classpath. > I hadn't really understood how that could work, and what it meant, > but now I think it does not mean *any* code from classpath, but > rather something that makes this 'dance' have less moves? > > ie it will not mean any code from classpath, rather just specific > code that the original author wants to use under grantback. > > Is that about right? No. These discussions are aimed at *any* code AFAIK. However, I am pretty sure that these discussions will take a significant time, less time that is likely needed for me to go through the copyright grantback procedure for the couple of files in question. And the end result of these discussions isn't clear either (although I hope it will turn out to be good). /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 mark at klomp.org Tue Jun 12 11:52:50 2007 From: mark at klomp.org (Mark Wielaard) Date: Tue, 12 Jun 2007 18:52:50 +0000 (UTC) Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <466D8A79.4070909@Sun.COM> <1181587836.10925.15.camel@mercury> <466ED392.9060709@Sun.COM> <1181669571.6063.38.camel@mercury> <466EDD4E.3080306@sun.com> <1181672240.11799.9.camel@mercury> Message-ID: Roman Kennke writes: > > > The remaining issue is > > > that the copyright is assigned to the FSF. I have hoped that you would > > > review my code before I start the copyright grantback dance for that > > > code. I am currently discussing this issue with Tom Marble and Mark > > > Wielaard. > > > > What is the copyright grantback dance? If you wrote the code what > > possible issue can there be? No one should be able to take away > > your rights to your code. > > Frankly a lot of this is still learning for us. > > When I wrote this code for GNU Classpath, I assigned copyright to the > FSF, just like OpenJDK contributions are copyright-assigned to Sun. With > the difference that the SCA is automatically granting the contributor > all rights to the code, while with the FSF CA I need to go through a > copyright grantback procedure, in order to make sure that all the code I > 'want back' was originally written by myself. To clarify, in most GNU projects for which the FSF is the guardian there is a process similar to the SCA. The individual contributing the code signs a contract with the FSF (that an officer of the FSF counter signs) and when appropriate a company disclaimer is filed with the FSF that employees are allowed to make contributions to the project. The contract assigns copyright of the code to the FSF, that way the FSF can make sure all code they distribute is clean and they can eaily guard the copyleft provisions of the project. In return the FSF promises to only release the contributed code or any derivative work under free terms to the public at large (this is also the reason the FSF cannot grant any extra rights to Sun to take any of that code proprietary). The contributor does get a grantback of all the rights assigned to the FSF if they request those. They FSF explicitly asks the contributor to notify them if they are exercising their grantback rights so they can put that information in their books (that way whenever they see a copy of that particular code without the normal FSF GPL copyright statement on it, they know to first ask the contributor whether or not they authorized that and not immediately assume that the copyright notices on that work are wrong/infringing). Till now, nobody having contributed code to the GNU Classpath project has ever exercised their grantback rights. So this is also new to us, and takes some work to properly do the correct paperwork. > > And when legal etc say we can only look at contributions made under > > an SCA, we pretty much have to do what they say. Perhaps > > there are other rules which allow it but I don't know that, > > and as an individual engineer I don't want to be making calls myself. > > I'd probably get me or Sun in trouble if I did. > > I understand this very much. Indeed. And you could see FSF-legal as being the counterpart of Sun-legal in our case. We like to do all the right things and not get the FSF in trouble or make them do any unnecessary work. Which is why we are also a little careful to first ask whether the code is really good enough/fits your scheme before involving the FSF legal department. > > The rush (it was a close thing even if that's not apparent) > > to get the source launched for JavaOne meant that we are nowhere > > near on the infrastructure to support it etc. > > This is understood too. No worries Yes, we do appreciate this! It is a really large step for all of you involved. Sorry if we seem a little bit too eager at times. But our intentions are good really, we do want to see openjdk happen and become a big and large community of enthousiastic people around the java source code. Cheers, Mark From mark at klomp.org Tue Jun 12 11:23:10 2007 From: mark at klomp.org (Mark Wielaard) Date: Tue, 12 Jun 2007 18:23:10 +0000 (UTC) Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <466D8A79.4070909@Sun.COM> <1181587836.10925.15.camel@mercury> <466ED392.9060709@Sun.COM> Message-ID: Dmitri Trembovetski writes: > Roman Kennke wrote: > However, in this case it will be useful for everybody > else to understand the restrictions under which we currently > operate. Thanks, that is useful. > I don't think it's Sun only policy, pretty much any company has it. > It is easy to become tainted by looking at other's people code. > The fact that the code is open-source doesn't matter, since > it's a question of copyright. Note that the copyright isn't in question in this case since it all comes from GNU Classpath. It is exactly the same as OpenJDK is already using (GPL + classpath) and you can be sure that the FSF made sure sure all that code is as clean as can be. They are kind of pedantic about that :) > > I think it would make sense to at least provide read access to the real > > group workspace (if you're paranoid then maybe only to group members, > > but then comes the question, how can anybody become a group member?). > > I'll see if we could arrange that. I believe that it is our > intention anyway - once we move to Mercurial each "group" will have > their read/write mercurial workspace and members of the group > will have read and in some cases write access. After having played with mercurial a bit I am really looking forward to the full rollout. It seems a very good pick for the way openjdk is setup. Cheers, Mark From roman.kennke at aicas.com Tue Jun 12 12:26:54 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 12 Jun 2007 21:26:54 +0200 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <466D8A79.4070909@Sun.COM> <1181587836.10925.15.camel@mercury> <466ED392.9060709@Sun.COM> Message-ID: <1181676414.11799.21.camel@mercury> Hi Mark, > > I don't think it's Sun only policy, pretty much any company has it. > > It is easy to become tainted by looking at other's people code. > > The fact that the code is open-source doesn't matter, since > > it's a question of copyright. > > Note that the copyright isn't in question in this case since it all comes from > GNU Classpath. It is exactly the same as OpenJDK is already using (GPL + > classpath) and you can be sure that the FSF made sure sure all that code is as > clean as can be. They are kind of pedantic about that :) Yeah, but it's still copyrighted by the FSF. I think this is the problem. It really doesn't matter from a legal POV if the license is the same. License != copyright owner. Copying FSF code would be copyright infringing, regardless of the actual license. Yes it is a good learning exercide trying to defend 'the other side' ;-) /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 mr at sun.com Tue Jun 12 22:10:00 2007 From: mr at sun.com (Mark Reinhold) Date: Tue, 12 Jun 2007 22:10:00 -0700 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: roman.kennke@aicas.com; Tue, 12 Jun 2007 19:32:51 +0200; <1181669571.6063.38.camel@mercury> Message-ID: <20070613051000.D0B6A6432@callebaut.niobe.net> > From: roman.kennke at aicas.com > Date: Tue, 12 Jun 2007 19:32:51 +0200 > ... >>> I think it would make sense to at least provide read access to the real >>> group workspace (if you're paranoid then maybe only to group members, >>> but then comes the question, how can anybody become a group member?). >> >> I'll see if we could arrange that. I believe that it is our >> intention anyway - once we move to Mercurial each "group" will have >> their read/write mercurial workspace and members of the group >> will have read and in some cases write access. >> >> But at this point even a read-only svn workspace would help. svn, or Mercurial? Would updates from the Sun-internal group workspaces once or twice a day be sufficient? (More than that could be tricky.) We're looking into setting something up short-term in order to ease this particular pain point. Due to hardware limitations it likely won't be available to the general public, but we want to do whatever we can to facilitate collaborative development even prior to the full Mercurial changeover. - Mark From roman.kennke at aicas.com Wed Jun 13 00:49:08 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Wed, 13 Jun 2007 09:49:08 +0200 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <20070613051000.D0B6A6432@callebaut.niobe.net> References: <20070613051000.D0B6A6432@callebaut.niobe.net> Message-ID: <1181720948.5905.1.camel@mercury> Hello Mark, > >>> I think it would make sense to at least provide read access to the real > >>> group workspace (if you're paranoid then maybe only to group members, > >>> but then comes the question, how can anybody become a group member?). > >> > >> I'll see if we could arrange that. I believe that it is our > >> intention anyway - once we move to Mercurial each "group" will have > >> their read/write mercurial workspace and members of the group > >> will have read and in some cases write access. > >> > >> But at this point even a read-only svn workspace would help. > > svn, or Mercurial? Both is perfectly fine for me. Personally I'd prefer hg. > Would updates from the Sun-internal group workspaces once or twice a day > be sufficient? (More than that could be tricky.) Sure. That is much better than once in 2-3 weeks or so ;-) > We're looking into setting something up short-term in order to ease this > particular pain point. Due to hardware limitations it likely won't be > available to the general public, but we want to do whatever we can to > facilitate collaborative development even prior to the full Mercurial > changeover. Great! Thanks for going through this. /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 Dmitri.Trembovetski at Sun.COM Wed Jun 13 11:45:53 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 13 Jun 2007 11:45:53 -0700 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <466ED392.9060709@Sun.COM> References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <466D8A79.4070909@Sun.COM> <1181587836.10925.15.camel@mercury> <466ED392.9060709@Sun.COM> Message-ID: <46703B61.8070702@Sun.COM> Dmitri Trembovetski wrote: >> I have to ask my boss(es). I believe that I am the copyright holder of >> that code because I didn't write it in my work time, and not for the >> purpuse of using it in the JamaicaVM, and I submitted this particular >> piece of code under my personal FSF copyright assignment. But it is no >> problem for me to sign the SCA myself too. However, as I pointed out, >> I'd first hear your opinion if that code is useful for you before I >> start the copyright-grantback dance with the FSF. I hope that doesn't >> cause a deadlock (if it really does, I might rethink, but it is my hope >> that Sun opens up a little more in this respect). > > I'm afraid that we won't be able to look at it until > you sign the SCA. Looks like there's some sanity left in this world. We got a clarification from our lawyers that we're allowed to look at the code for "evaluation purposes" without the contributor having to sign the SCA. It indeed seemed very silly to force people to share the copyright to the code just so that we can look at it. However, in order for it to be integrated the submitter will still have to sign the SCA, obviously. Thanks, Dmitri From Jim.A.Graham at Sun.COM Wed Jun 13 17:52:32 2007 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Wed, 13 Jun 2007 17:52:32 -0700 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <1180041811.6039.35.camel@mercury> References: <1180041811.6039.35.camel@mercury> Message-ID: <0JJL00A4FP3356F0@fe-sfbay-10.sun.com> I'm starting to look at this now, but first I wanted to give some feedback on the technical notes below: Roman Kennke wrote: > I finished up what I wanted to add to my rasterizer and want to make it > available to anybody who would like to review it or play with it. You > can download the code here: > > http://kennke.org/~roman/rasterizer-rkennke-2007-05-24.zip > > Technical notes: > - The entry point is the ScanlineConverter class. I have an instance of > this in my Graphics2D implementation and store it as a thread local I'd rather see it stored in a global cache so that we don't leak one if a thread does a little bit of rendering and then goes off to do only non-rendering tasks from that point onward. > - In order to convert this information to the tiles that you need, it > shouldn't be too hard to implement a Pixelizer that aggregates a couple > of scanlines into tiles. The interesting task here is to do this > efficiently. If we stick with a 32x32 tile size to be kind to the current tradeoffs in the OpenGL pipeline then it would need enough memory to rasterize 32 scanlines at a time. That's not huge, but it would be nice to do better. For the short term, I think it would work nicely. > - The rasterizer is a generic Shape rasterizer. I believe it is very > efficient for rasterizing arbitrary Shape objects, plus transform and > clipping. It uses a sophisticated scanline algorithm (if you want it, I > can write more about this, but this is going to be a small essay > then.. ;-) ). However, it is not (yet) optimized for certain frequent > special cases. Most importantly, I think lines and rectangles could be > done much faster in certain settings. I'll add that in the future. It would be nice to have special case rasterizers for common objects if they can be managed in a small space. I'll probably see as I review the implementation, but one question I have off hand is whether or not it handles STROKE_NORMALIZE vs. STROKE_PURE? Also, does it work for stroking shapes directly, or does it rely on BasicStroke.createStrokedShape(), or is there another rendering process entirely for stroked shapes? > - Most calculations are done using fixed point arithmetics (that's > because the original target have been platforms without FPU). I don't > know if that does any good for performance on usual desktop systems, but > it won't do any harm either. I think that all of our code uses fixed point in the final rendering loops, but it does most of the geometrical calculations in float or double. We are currently evaluating another renderer from the embedded group that also converts to fixed point very early on. One of the things we would have to evaluate for either body of code long term is if it can deal with large coordinates gracefully or if it overflows or crashes. Our current code has (mostly, if not entirely) been vetted to deal with arbitrarily large coordinates (I say mostly because I don't know that we have full coverage on the testing of that support yet). Long term we'd also like to share a rendering system with the embedded markets that would have the same restriction that you were worried about - missing or very poorly performing FPU. We may want to have one body of code that can work both ways depending on the target for a given integration - but that may involve either doing it all natively or coming up with some kind of Java preprocessor so the code could be refactored for different numeric strategies prior to compilation. > - Datastructures are reused in almost all cases. That means that the > scanline converter doesn't allocate any new memory once it has its > datastructures set up after a couple of rendering cycles. New > allocations only happen when the datastructures need to be extended > (e.g. for extraordinary complex shapes). How large can this grow? Is it a potential problem if a program draws one really really huge shape and then goes back to really small shapes for the rest of its lifespan? ...jim From Jim.A.Graham at Sun.COM Wed Jun 13 21:46:51 2007 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Wed, 13 Jun 2007 21:46:51 -0700 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <1180041811.6039.35.camel@mercury> References: <1180041811.6039.35.camel@mercury> Message-ID: <0JJL0094MZXMUB20@fe-sfbay-10.sun.com> Some preliminary thoughts in looking over the ScanlineConverter... - It does quite a lot for such a small piece of code - very cool. - It's also very basic in its mathematical techniques, though. The math to trace the slope of a line is inefficient and inaccurate and it flattens everything before tracing. There is a lot of room for improvement here. - It uses a push technology - you call it with something to render, it then calls something else with the data to render. This is opposite the designs in our pipeline which call the rasterizer and ask it to return the path coverage information and then hand the path coverage information off to a pixel pusher. It will be hard to turn that calling sequence around for this code unfortunately to make it match the way we do things in our pipelines currently (via AATileGenerator). Not impossible, it will just require slicing up the code a bit on one side or another. - It ignores the winding rule of the path, shouldn't be too hard to add support for non-zero winding, though. - Clipping is managed by rasterizing both the shape and the clip at the same time. The advantage of rasterizing the clip along with the shape is that you can rasterize the clip at a higher resolution when doing AA, but it comes with some drawbacks: - It's easy for the Shape rasterizer to rasterize both at the same time, but other parts of the pipeline (text and imaging) won't be so lucky without a lot of added support code. - Clipping should restrict the same regardless of pipeline and attributes set, but this clipping will restrict AA and non-AA rendering differently (due to different resolutions). It might also restrict rendering of text and image differently unless they duplicate its code. - There are a lot of calculations involved in rasterizing the clip each time something is rendered - a big performance hit. - Since our pipelines manage clipping outside of the AATileGenerator, the clipping code could be ignored when adapting this code as a plugin for the AATG, so the above drawbacks won't have any immediate impact in the short term and we can discuss them for longer term use when we get to more extensive efforts at coming up with a new "best of breed" renderer. In the end, I think we'll probably want to stick with our Region based clipping for performance and ease of integration, but that all remains TBD. - There is little to no handling of large coordinates, the results of handling them are a by-product of the calculation used to convert them to fixed point. - The slope calculation doesn't carry very much precision at all - it looks like the error can be as much as +/- 1 pixel for every 64 samplings. There are much better ways to manage the math there that provide much more accuracy. The code in src/share/native/sun/java2d/pipe/ShapeSpanIterator.c traces the slope of flattened shapes much more accurately. - We found some performance improvements in directly tracing the curves rather than flattening them. These techniques are evidenced in the src/share/classes/sun/java2d/loops/ProcessPath.java code (also mirrored at the native level in src/share/native/sun/java2d/loops/ProcessPath.c). I'd say for the short term, it might help get us off the ground wrt satisfying the AATileGenerator interface, but there are probably some simpler ways to achieve that end. I have a quick and dirty prototype of using Region objects to generate alpha tiles that I'll try to clean up and throw out here for another straw man. It performed about .1 to .5x of the speed of the production code, but it was small and simple and took Ductus out of the equation. The one piece that neither my quick Region hack nor this Rasterizer that you are offering here satisfy is an alternate implementation of line widening... ...jim From roman.kennke at aicas.com Mon Jun 18 02:53:49 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Mon, 18 Jun 2007 11:53:49 +0200 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <0JJL0094MZXMUB20@fe-sfbay-10.sun.com> References: <1180041811.6039.35.camel@mercury> <0JJL0094MZXMUB20@fe-sfbay-10.sun.com> Message-ID: <1182160429.6002.31.camel@mercury> Hi Jim, > - It's also very basic in its mathematical techniques, though. The math > to trace the slope of a line is inefficient and inaccurate and it > flattens everything before tracing. There is a lot of room for > improvement here. Indeed, that's true. > - It uses a push technology - you call it with something to render, it > then calls something else with the data to render. This is opposite the > designs in our pipeline which call the rasterizer and ask it to return > the path coverage information and then hand the path coverage > information off to a pixel pusher. It will be hard to turn that calling > sequence around for this code unfortunately to make it match the way we > do things in our pipelines currently (via AATileGenerator). Not > impossible, it will just require slicing up the code a bit on one side > or another. Yeah right. That shouldn't be a problem to change. > - It ignores the winding rule of the path, shouldn't be too hard to add > support for non-zero winding, though. Right. > - Clipping is managed by rasterizing both the shape and the clip at the > same time. The advantage of rasterizing the clip along with the shape > is that you can rasterize the clip at a higher resolution when doing AA, > but it comes with some drawbacks: > > - It's easy for the Shape rasterizer to rasterize both at the > same time, but other parts of the pipeline (text and imaging) > won't be so lucky without a lot of added support code. Yeah I was thinking about that too. However, 'our' (== aicas) rendering renders everything using this rasterizer. For text it fetches the outline shape of the glyphs and rasterizes them and for images it does something like rendering a rectangle with a Texture-like Paint. For target systems that offer better/optimized functions for these cases we use the native libs of course. > - Clipping should restrict the same regardless of pipeline and > attributes set, but this clipping will restrict AA and non-AA > rendering differently (due to different resolutions). It might > also restrict rendering of text and image differently unless > they duplicate its code. > > - There are a lot of calculations involved in rasterizing the > clip each time something is rendered - a big performance hit. True. However, the clipping can simply be ignored or ripped out of you don't need this. Should make the code simpler and faster. > - There is little to no handling of large coordinates, the results of > handling them are a by-product of the calculation used to convert them > to fixed point. It should be easy to do all calculations using float or double rather than fixed point. > - The slope calculation doesn't carry very much precision at all - it > looks like the error can be as much as +/- 1 pixel for every 64 > samplings. There are much better ways to manage the math there that > provide much more accuracy. The code in > src/share/native/sun/java2d/pipe/ShapeSpanIterator.c traces the slope of > flattened shapes much more accurately. I'll have a look there. > - We found some performance improvements in directly tracing the curves > rather than flattening them. These techniques are evidenced in the > src/share/classes/sun/java2d/loops/ProcessPath.java code (also mirrored > at the native level in src/share/native/sun/java2d/loops/ProcessPath.c). Cool, I will study that too :-) > I'd say for the short term, it might help get us off the ground wrt > satisfying the AATileGenerator interface, but there are probably some > simpler ways to achieve that end. I have a quick and dirty prototype of > using Region objects to generate alpha tiles that I'll try to clean up > and throw out here for another straw man. It performed about .1 to .5x > of the speed of the production code, but it was small and simple and > took Ductus out of the equation. Nice. I ask myself if it is worth the effort to continue with my ScanlineConverter and friends classes. There are not only the technical issues that you outlined above (plus more that might creep up), it also seems to be difficult to find a quick-enough solution for the legal stuff. An anti-aliasing rasterizer shouldn't be too much code anyway, and it might be worth starting from scratch (or from your prototype), with the special need of OpenJDK (and existing code in OpenJDK) in mind. What do you think? > The one piece that neither my quick Region hack nor this Rasterizer that > you are offering here satisfy is an alternate implementation of line > widening... Yeah, my implementation relies on BasicStroke for that. Too bad. I haven't really looked into the geometry of that path stuff. How's the read-only HG and/or SVN workspace for Java2D going? /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 mark at klomp.org Mon Jun 18 02:13:09 2007 From: mark at klomp.org (Mark Wielaard) Date: Mon, 18 Jun 2007 11:13:09 +0200 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <1181676414.11799.21.camel@mercury> References: <1180041811.6039.35.camel@mercury> <46561F45.60709@sun.com> <1181337589.5898.39.camel@mercury> <466D8A79.4070909@Sun.COM> <1181587836.10925.15.camel@mercury> <466ED392.9060709@Sun.COM> <1181676414.11799.21.camel@mercury> Message-ID: <1182157989.3097.1.camel@localhost.localdomain> On Tue, 2007-06-12 at 21:26 +0200, Roman Kennke wrote: > Hi Mark, > > > > I don't think it's Sun only policy, pretty much any company has it. > > > It is easy to become tainted by looking at other's people code. > > > The fact that the code is open-source doesn't matter, since > > > it's a question of copyright. > > > > Note that the copyright isn't in question in this case since it all comes from > > GNU Classpath. It is exactly the same as OpenJDK is already using (GPL + > > classpath) and you can be sure that the FSF made sure sure all that code is as > > clean as can be. They are kind of pedantic about that :) > > Yeah, but it's still copyrighted by the FSF. I think this is the > problem. It really doesn't matter from a legal POV if the license is the > same. License != copyright owner. Copying FSF code would be copyright > infringing, regardless of the actual license. No, copying FSF code is (by definition, since it will always be Free Software) never a problem as long as the free software distribution terms are followed and the actual copyright notice itself is retained on the copy. Then it isn't copyright infringement since you have explicit rights to do the copying. just like you have the right to copy and redistribute with or without changes the rest of the OpenJDK source code since that is distributed under the same terms. Both projects (GNU Classpath see the LICENSE, OpenJDK see the README_THIRD_PARTY files) already contain "external" code from other copyright holders that is distributed with the larger work, for which everybody has the right to redistribute. That is the beauty of Free Software licenses :) Cheers, Mark From Jim.A.Graham at Sun.COM Mon Jun 18 17:44:29 2007 From: Jim.A.Graham at Sun.COM (Jim Graham) Date: Mon, 18 Jun 2007 17:44:29 -0700 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <1182160429.6002.31.camel@mercury> References: <1180041811.6039.35.camel@mercury> <0JJL0094MZXMUB20@fe-sfbay-10.sun.com> <1182160429.6002.31.camel@mercury> Message-ID: <0JJU00DTRXY45JF0@fe-sfbay-10.sun.com> > True. However, the clipping can simply be ignored or ripped out of you > don't need this. Should make the code simpler and faster. It won't be needed to satisfy the needs of the RenderingEngine plugin API that I sent out a few days ago. Longer term we may want to stick with Region clipping as well, but the other bullet items I wrote on the subject will represent the start of a design discussion on that front. >> - There is little to no handling of large coordinates, the results of >> handling them are a by-product of the calculation used to convert them >> to fixed point. > > It should be easy to do all calculations using float or double rather > than fixed point. There really aren't many calculations to do in fp/double in the first place. If you look at the code pointers I sent out they go straight to integer incremental calculations fairly directly from the output of the flattening code. The odd thing about what you had written is that you actually caused quite a lot of floating point calculations to be done when you asked the starting shape for a flattened iteration - that is done by subdividing in floating point, which is a lot of calculations - certainly more than are required to take the flattened results and calculate scanline stepping values from it. (With respect to the 2 pieces of code that I pointed you to, the ProcessPath stuff is newer but rounds to integers right after flattening the shape - the ShapeSpanIterator stuff is older, but it maintains sub-pixel accuracy even as it traces the flattened outline. The primary improvements in the ProcessPath stuff are the way that it traces the curves to generate the line segments and how it deals with STROKE_PURE vs. STROKE_NORMALIZE to keep the curves rounder...) > I ask myself if it is worth the effort to continue with my > ScanlineConverter and friends classes. There are not only the technical > issues that you outlined above (plus more that might creep up), it also > seems to be difficult to find a quick-enough solution for the legal > stuff. An anti-aliasing rasterizer shouldn't be too much code anyway, > and it might be worth starting from scratch (or from your prototype), > with the special need of OpenJDK (and existing code in OpenJDK) in mind. > What do you think? My prototype doesn't perform well enough to be seriously considered. I checked it into the workspace so that it will arrive in the OpenJDK repository (hopefully) at the same time as the Pluggable interface does. You will find it in src/share/demo/java2d/. It's mainly there to prove that the Pluggable interface can be plugged with alternate code, but in terms of a serious contender for the OpenJDK plug I think a modified version of your code with the accuracy problems fixed and turned into a pull technology instead of a push technology is likely more promising from a performance perspective. That, or the ME code that we've been evaluating internally, but that is about as far from what we need as your code and it relies on fixed point in a more systemic way that will be harder to factor out. > How's the read-only HG and/or SVN workspace for Java2D going? I'm not working on that - I'll ping the people involved... ...jim From Dmitri.Trembovetski at Sun.COM Tue Jun 19 13:42:51 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Tue, 19 Jun 2007 13:42:51 -0700 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <0JJU00DTRXY45JF0@fe-sfbay-10.sun.com> References: <1180041811.6039.35.camel@mercury> <0JJL0094MZXMUB20@fe-sfbay-10.sun.com> <1182160429.6002.31.camel@mercury> <0JJU00DTRXY45JF0@fe-sfbay-10.sun.com> Message-ID: <46783FCB.3070204@Sun.COM> >> How's the read-only HG and/or SVN workspace for Java2D going? > > I'm not working on that - I'll ping the people involved... I'm told we're still working on it. Our team workspace suffering corruption yesterday didn't help (already restored). Thanks for the patience. Thanks, Dmitri From Dmitri.Trembovetski at Sun.COM Fri Jun 22 08:25:19 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Fri, 22 Jun 2007 08:25:19 -0700 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <0JJU00DTRXY45JF0@fe-sfbay-10.sun.com> References: <1180041811.6039.35.camel@mercury> <0JJL0094MZXMUB20@fe-sfbay-10.sun.com> <1182160429.6002.31.camel@mercury> <0JJU00DTRXY45JF0@fe-sfbay-10.sun.com> Message-ID: <467BE9DF.2000905@Sun.COM> FYI, the build containing Jim's changes for the puggable rasterizer is finally out (see attached email). List of changes: http://download.java.net/jdk7/changes/jdk7-b14.html Relevant bug id: 6566807: Need pluggable interface to facilitate OpenJDK replacement of encumbered Ductus components Thanks, Dmitri -------------- next part -------------- An embedded message was scrubbed... From: Xiomara Jayasena Subject: JavaSE 7 build 14 is available at the openjdk.java.net website Date: Thu, 21 Jun 2007 21:50:27 -0700 Size: 5542 Url: http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/attachments/20070622/084efdb0/attachment.mht From roman at kennke.org Fri Jun 22 08:35:49 2007 From: roman at kennke.org (Roman Kennke) Date: Fri, 22 Jun 2007 17:35:49 +0200 Subject: [OpenJDK Rasterizer] Rasterizer replacement proposal In-Reply-To: <467BE9DF.2000905@Sun.COM> References: <1180041811.6039.35.camel@mercury> <0JJL0094MZXMUB20@fe-sfbay-10.sun.com> <1182160429.6002.31.camel@mercury> <0JJU00DTRXY45JF0@fe-sfbay-10.sun.com> <467BE9DF.2000905@Sun.COM> Message-ID: <1182526549.6166.68.camel@mercury> Hi, > FYI, the build containing Jim's changes for > the puggable rasterizer is finally out (see attached > email). Yeah cool. I've already checked it out. I'll try to address Jim's 'complaints' as soon as possible. Unfortunately, the legal side of the story doesn't seem to pan out as easily as I expected. I received feedback from the FSF that the copyright is held by the FSF now, and there is no such thing like a grantback procedure. Instead, the original contributor is automatically granted back most rights that are covered by the copyright. The FSF and Sun are apparently discussing how to solve this problem. (FSF wouldn't sign the SCA generally because this means that the contributed code could also be used in commercial distributions, but they could make exceptions for special cases like this). /Roman -- http://kennke.org/blog/