Re: Proposal: Graphics2D rewrite branch
On Sun, 2005-12-11 at 18:02 -0700, Tom Tromey wrote: Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark And you should not see it as private or may be broken at random Mark times. It should be as much as possible something that you work with a Mark team on (and if there is no team - yet - then there is nothing as bad as Mark having a completely broken build to get others to help out). Actually, I think it is reasonable to have a may be broken branch. In fact this is one of the main reasons for having a branch -- if you can keep stuff building and working, in many cases you won't need a branch at all. Yeah, this may be a bit too strong. I meant it as a strong warning that the branch cannot be a dumping ground for some code that isn't even supposed to work. I'll reformulate that as: @item A branch should not be seen as ``private'' or ``may be completely broken''. It should be as much as possible something that you work on with a team (and if there is no team - yet - then there is nothing as bad as having a completely broken build to get others to help out). There can of course be occasional breakage, but it should be planned and explained. And you can certainly have a rule like ``please ask me before committing to this branch''. Let me know if that still doesn't capture the spirit. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
Hi, On Wed, 2005-12-07 at 12:05 -0700, Tom Tromey wrote: Tom == Thomas Fitzsimmons [EMAIL PROTECTED] writes: Tom I'd like to propose a new branch in the GNU Classpath CVS repository: Tom graphics2d-rewrite. Patches to this branch should be sent to Tom classpath-patches@gnu.org with a subject line prefix of [g2d rewrite]. Tom Commit policy is the same as GNU Classpath trunk. I say go for it. Yes, if you think you need a branch for this rewrite please do (call it something descriptive like cairo-graphics2d). I can see that if you want to just phase out GdkGraphics and always use a new setup around CairoGraphics2D that it might be nice to have a branch to not disturb the work of others. But as said by some others if at all possible do the work on the trunk. That does make it easier for others to follow/help out. Furthermore I think we should adopt gcc-ish branch rules. These are pretty reasonable and have proven to work well in practice. Namely: * Any Classpath developer can make a branch for any purpose. All branches ought to be documented somewhere, so we can know which are live, who owns them, and when they die. I don't know where we would put this though (suggestions?) I'll create a page in the wiki http://developer.classpath.org/mediation/ClasspathBranches * Some rules can be changed on a branch. In particular the branch maintainer can change the review requirements, and the requirement of keeping things building, testing, etc, can also be lifted. (These should be documented along with the branch name and owner if they differ from the trunk.) Requirements for patch email to classpath-patches and for paperwork *cannot* be lifted. And you should not see it as private or may be broken at random times. It should be as much as possible something that you work with a team on (and if there is no team - yet - then there is nothing as bad as having a completely broken build to get others to help out). * Merges from the trunk to a branch are at the discretion of the branch maintainer. * A merge from a branch to the trunk is treated like any other patch. In particular, it has to go through review, it must satisfy all the trunk requirements (build, regression test, documentation). This rule prevents folks from working around trunk rules by making a branch :-) These rules sound very good. I will add them to the Hacking Guide. There may be additional timing requirements on merging a branch to the trunk depending on the release schedule, etc. For instance we may not want to do a branch merge just before a release. Good point. I believe we do communicate very well on the mailing-lists. So I don't think this will ever be a problem. But the release master (which seems to be me atm, although we never officially created that role) should have a veto in the last few weeks before a stable release for any branch - trunk merges. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Requirements for patch email to classpath-patches and for paperwork *cannot* be lifted. Mark And you should not see it as private or may be broken at random Mark times. It should be as much as possible something that you work with a Mark team on (and if there is no team - yet - then there is nothing as bad as Mark having a completely broken build to get others to help out). Actually, I think it is reasonable to have a may be broken branch. In fact this is one of the main reasons for having a branch -- if you can keep stuff building and working, in many cases you won't need a branch at all. As for private, I think we should be careful. Nothing in Classpath can truly be private, the point is we're building something in common. But it can be reasonable to have a rule like, 'please ask me before committing to this branch'. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[cp-patches] Re: Proposal: Graphics2D rewrite branch
Am Donnerstag, den 08.12.2005, 13:20 + schrieb theUser BL: On this branch I'd like to do several things: 1) Make Graphics2D the default 2) Remove Graphics What do you mean with this? Does this mean, that Graphics is based on Graphics2D and so for plain AWT or Swing programs Cairo is needed? I don't hope so. I have the hope, that it goes in any time the other way around, that Graphics2D is based on Graphics and created with the plain AWT-Graphics. This would indeed be cool to have, though I doubt this is what fitzsim is going to do. As in other areas of Classpath it would be nice to have a Java-only (easily portable) variant and a version that is backed by some native lib. What I don't understand, why do we need a new branch here? The build-time and runtime-switches seem sufficient to me for now. And when the impl is somewhat complete, these switches could be easily changed to make Graphics2D the default. /Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Re: Proposal: Graphics2D rewrite branch
On Thu, 2005-12-08 at 18:01 +0100, Roman Kennke wrote: What I don't understand, why do we need a new branch here? The build-time and runtime-switches seem sufficient to me for now. And when the impl is somewhat complete, these switches could be easily changed to make Graphics2D the default. I was wondering the same thing. We used to branch libgcj for advanced GUI hacking, but I think that was because people were sensitive to breaking the GCC builds. But now we're just talking about the GNU Classpath repository, where people will likely be more tolerant of breakage (not that it happened much in our libgcj branch). I guess I don't care much either way. Just curious. AG ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Re: Proposal: Graphics2D rewrite branch
On Thu, 2005-12-08 at 18:01 +0100, Roman Kennke wrote: Am Donnerstag, den 08.12.2005, 13:20 + schrieb theUser BL: On this branch I'd like to do several things: 1) Make Graphics2D the default 2) Remove Graphics What do you mean with this? Does this mean, that Graphics is based on Graphics2D and so for plain AWT or Swing programs Cairo is needed? I don't hope so. I have the hope, that it goes in any time the other way around, that Graphics2D is based on Graphics and created with the plain AWT-Graphics. This would indeed be cool to have, though I doubt this is what fitzsim is going to do. As in other areas of Classpath it would be nice to have a Java-only (easily portable) variant and a version that is backed by some native lib. What I don't understand, why do we need a new branch here? The build-time and runtime-switches seem sufficient to me for now. And when the impl is somewhat complete, these switches could be easily changed to make Graphics2D the default. I just don't want to disrupt the progress of Swing and I don't want to do all the work on my local machine either. A branch seemed like a good trade-off. The changes I'll be making will likely be pretty invasive. I'm not sure at this point that --disable-gtk-cairo will be enough insulation so I thought a branch was safer. It would also allow me to make bigger/riskier changes that may not even build after a check-in (a freedom that I like to have when doing rewrites like this). All that said, I could try just working on mainline if people would rather that and could put up with some transient breakage. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: Proposal: Graphics2D rewrite branch
On this branch I'd like to do several things: 1) Make Graphics2D the default 2) Remove Graphics What do you mean with this? Does this mean, that Graphics is based on Graphics2D and so for plain AWT or Swing programs Cairo is needed? I don't hope so. I have the hope, that it goes in any time the other way around, that Graphics2D is based on Graphics and created with the plain AWT-Graphics. So it would also be easier to port free Javas to Windows and MacOSX. Something like Sun does with its implementation. So that on Windows and MacOSX only the bindings to GTK+ are ported to the Windows-API and the Aqua-API. But if Cairo is needed, it seems, that you also need later on Windows and MacOSX Cairo. And that is something what I don't like. Greatings theuserbl ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
On Thu, 2005-12-08 at 13:20 +, theUser BL wrote: On this branch I'd like to do several things: 1) Make Graphics2D the default 2) Remove Graphics What do you mean with this? I meant remove GdkGraphics. Does this mean, that Graphics is based on Graphics2D and so for plain AWT or Swing programs Cairo is needed? I don't hope so. I have the hope, that it goes in any time the other way around, that Graphics2D is based on Graphics and created with the plain AWT-Graphics. Yes, inheritance in java.awt will work the same way, with Graphics2D inheriting from Graphics. It's just that we'll only have a peer that wraps Cairo and not a peer that wraps GDK drawing primitives. So the inheritance graph will be: Graphics - Graphics2D - CairoGraphics2D - ... with the ... representing specialized graphics objects for different surfaces. So it would also be easier to port free Javas to Windows and MacOSX. Something like Sun does with its implementation. So that on Windows and MacOSX only the bindings to GTK+ are ported to the Windows-API and the Aqua-API. But if Cairo is needed, it seems, that you also need later on Windows and MacOSX Cairo. And that is something what I don't like. This rewrite will make the GTK AWT peers depend on GTK-2.8 which in turn depends on Cairo so avoiding a Cairo dependency is impossible if we want to move to newer GTK releases. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
Hello, Great that there is a rewrite of Graphics2D *yipie* I would be interrested to hear some thoughts about a single threaded rendering pipeline as Sun's OpenGL pipeline uses. Is Cairo threadsafe itself or does Classpath take care? lg Clemens ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
Tom == Thomas Fitzsimmons [EMAIL PROTECTED] writes: Tom I'd like to propose a new branch in the GNU Classpath CVS repository: Tom graphics2d-rewrite. Patches to this branch should be sent to Tom classpath-patches@gnu.org with a subject line prefix of [g2d rewrite]. Tom Commit policy is the same as GNU Classpath trunk. I say go for it. Furthermore I think we should adopt gcc-ish branch rules. These are pretty reasonable and have proven to work well in practice. Namely: * Any Classpath developer can make a branch for any purpose. All branches ought to be documented somewhere, so we can know which are live, who owns them, and when they die. I don't know where we would put this though (suggestions?) * Some rules can be changed on a branch. In particular the branch maintainer can change the review requirements, and the requirement of keeping things building, testing, etc, can also be lifted. (These should be documented along with the branch name and owner if they differ from the trunk.) Requirements for patch email to classpath-patches and for paperwork *cannot* be lifted. * Merges from the trunk to a branch are at the discretion of the branch maintainer. * A merge from a branch to the trunk is treated like any other patch. In particular, it has to go through review, it must satisfy all the trunk requirements (build, regression test, documentation). This rule prevents folks from working around trunk rules by making a branch :-) There may be additional timing requirements on merging a branch to the trunk depending on the release schedule, etc. For instance we may not want to do a branch merge just before a release. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
Thomas Fitzsimmons wrote: Hi, I'd like to propose a new branch in the GNU Classpath CVS repository: graphics2d-rewrite. Patches to this branch should be sent to classpath-patches@gnu.org with a subject line prefix of [g2d rewrite]. Commit policy is the same as GNU Classpath trunk. On this branch I'd like to do several things: 1) Make Graphics2D the default 2) Remove Graphics 3) Split Graphics2D according to http://developer.classpath.org/mediation/ClasspathGraphicsImagesText Once these items are done and tested to work as well or better than the current Graphics/Graphics2D implementations, I'll merge the branch into trunk and continue development there. Any objections? Tom I'm looking forward to seeing this work proceed. I can certainly help with testing, but I'm not likely to be much help with the actual implementation (I know so little about the non-Java bits of GNU Classpath). Regarding 3) and BufferedImages, I think I recall Sven saying he was mistaken about the DataBuffer classes. As far as I could tell (from writing some Mauve tests for them) they use real Java arrays. And that makes using Cairo for BufferedImages more difficult, doesn't it? Regards, Dave ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
David Gilbert wrote:
Regarding 3) and BufferedImages, I think I recall Sven saying he was
mistaken about the DataBuffer classes. As far as I could tell (from
writing some Mauve tests for them) they use real Java arrays.
It should be possible to have a hybrid implementation that can use
native buffers or Java arrays. If constructed using (say)
DataBufferInt(int size, int numBanks)
then it can allocated a native buffer.
The complicatation is getData and getBankData. If using native buffers,
these would have to allocate new buffers, copy the data of of the
native buffers, release the native buffers, and switch to using the
Java arrays for future references.
This isn't too bad if you're using CNI and a non-copying gc, since
you can use a native pointer in all cases, and just have the
natve pointer point into the Java arrray in the Java case.
If using a copying GC, you can use a delta. For simplicity, I
assume a single bank:
DataBufferInt {
int[] array;
native size_t offset;
int getElem(int i) { return *(int*)((char*) array + offset + 4 * i); }
DataBufferInt(int size) {
void* buf = allocate_native_buffer(size);
array = null;
offset = buf;
}
DataBufferInt(int[] arr) {
array = arr;
offset = SIZE_OF_ARRAY_HEADER;
}
int[] getData () {
int[] ar = new int[size];
copy_form_native_buffer_into(ar);
array = ar;
offset = SIZE_OF_ARRAY_HEADER;
}
}
This works even if the array is moved by the gc.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
