I'm finishing up a small project using GIL and I appreciate GIL even more -- I now have a very good feel for the basic functionality of the library. I'll post my sample project and some impressions of my experience here when I'm done. I'm still trying to learn the more advanced features of GIL -- my difficulty with the advanced functionality has nothing to do with GIL, but more my own deficiencies in understanding color theory. There are two things that I would absolutely must have if I was to completely switch over to GIL: 1) freetype - for text rendering I've started to write a freetype class for GIL that may be of interest. I'll send that to Lubomir it on when I'm done. 2) antaialias lines - for smooth line rendering Anatialias lines are more difficult, particularly connecting end points. I wonder what lubomir's plans are for this important functionality. I'm thinking something like this: for_each_line(lines.begin(), lines.end(), draw_antialised()); <or> for_each_point(points.begin(), points.end(), draw_antialiased());
Tom Brinkman wrote:
There are two things that I would absolutely must have if I was to completely switch over to GIL:
1) freetype - for text rendering I've started to write a freetype class for GIL that may be of interest. I'll send that to Lubomir it on when I'm done.
2) antaialias lines - for smooth line rendering Anatialias lines are more difficult, particularly connecting end points. I wonder what lubomir's plans are for this important functionality.
As far as I understand GIL, this is not the focus of the library. However, you can rely on third-party libraries to do this, for example http://www.antigrain.com/ (<=2.4 uses a quite liberal license) and http://www.cairographics.org/ . Both can render to memory buffers which in turn can be used directly in GIL. best regards, Malte
On 1/23/07, Malte Clasen <news@copro.org> wrote:
2) antaialias lines - for smooth line rendering Anatialias lines are more difficult, particularly connecting end
Tom Brinkman wrote: points. I
wonder what lubomir's plans are for this important functionality.
As far as I understand GIL, this is not the focus of the library.
It is not the current GIL focus but contributions or additions should be encouraged AGG is now GPL (and I believe is mainly developed by one person) so the boost approach should do much better with potentially multiple authors contributing new related image libraries regards jose However, you can rely on third-party libraries to do this, for example
http://www.antigrain.com/ (<=2.4 uses a quite liberal license) and http://www.cairographics.org/ . Both can render to memory buffers which in turn can be used directly in GIL.
Jose wrote:
It is not the current GIL focus but contributions or additions should be encouraged
Yes. I created a web page regarding GIL contributions: http://opensource.adobe.com/gil/contribute.html We would love to see people contribute to GIL and we will maintain links to GIL projects from the main GIL web site. Several people have already expressed interest and some have sent me code. Lubomir
Jose wrote:
On 1/23/07, Malte Clasen <news@copro.org> wrote:
Tom Brinkman wrote:
2) antaialias lines - for smooth line rendering Anatialias lines are more difficult, particularly connecting end
points. I
wonder what lubomir's plans are for this important functionality.
As far as I understand GIL, this is not the focus of the library.
It is not the current GIL focus but contributions or additions should be encouraged
AGG is now GPL (and I believe is mainly developed by one person) so the boost approach should do much better with potentially multiple authors contributing new related image libraries
Latest release of AGG, 2.5 has only very miner improvements over 2.4 which is licensed under "Modified BSD", in addition it is licenced under: Anti-Grain Geometry Public License Anti-Grain Geometry - Version 2.4 Copyright (C) 2002-2004 Maxim Shemanarev (McSeem) Permission to copy, use, modify, sell and distribute this software is granted provided this copyright notice appears in all copies. This software is provided "as is" without express or implied warranty, and with no claim as to its suitability for any purpose. Which may allow use of AGG 2.4 code in Boost under the boost license. Any thoughts on that? Note also that Anti-Grain Geometry distribution package includes General Polygon Clipper (GPC) by Alan Murta. GPC has a different kind of license that allows you to use Alan's work for free only in non-commercial software. See http://www.antigrain.com/license/index.html for details. By far the best thing would be to convince McSeem to contribute to boost if there are anybody that are able to persuade him. :-) regards, Bjørn Roald
On 1/24/07, Bjørn Roald <bjorn@4roald.org> wrote:
Which may allow use of AGG 2.4 code in Boost under the boost license. Any thoughts on that?
But 2.4 is an old release, so it looks like it wouldn't be a good idea to aim for serious AGG integration Note also that Anti-Grain Geometry distribution package includes General
Polygon Clipper (GPC) by Alan Murta. GPC has a different kind of license that allows you to use Alan's work for free only in non-commercial software.
See http://www.antigrain.com/license/index.html for details.
By far the best thing would be to convince McSeem to contribute to boost if there are anybody that are able to persuade him. :-)
Jose wrote:
On 1/24/07, Bjørn Roald <bjorn@4roald.org> wrote:
Which may allow use of AGG 2.4 code in Boost under the boost license. Any thoughts on that?
But 2.4 is an old release, so it looks like it wouldn't be a good idea to aim for serious AGG integration
It's not current, but far from being outdated. There seem to be several people (including me) who stick with it because of licensing issues. I'm quite sure that a branch starting at 2.4 could be successful from a user's perspective, considering the comments on the agg mailing list. However, without a motivated lead developer, this is going to be a dead end, since there's currently no AGG development community that could switch to the Boost branch. But if someone wants to start working on this, I'd say this is the time to do so. Malte
Malte Clasen wrote:
Jose wrote:
On 1/24/07, Bjørn Roald <bjorn@4roald.org> wrote:
Which may allow use of AGG 2.4 code in Boost under the boost license. Any thoughts on that?
But 2.4 is an old release, so it looks like it wouldn't be a good idea to aim for serious AGG integration
It's not current, but far from being outdated. There seem to be several people (including me) who stick with it because of licensing issues. I'm quite sure that a branch starting at 2.4 could be successful from a user's perspective, considering the comments on the agg mailing list. However, without a motivated lead developer, this is going to be a dead end, since there's currently no AGG development community that could switch to the Boost branch. But if someone wants to start working on this, I'd say this is the time to do so.
I agree. 2.4 is a good release. It's a good point for branching. I had high hopes for some work on antigrain, views and rendering and GIL. I did a quick demo on integration when GIL was reviewed. It's possible to fork Antigrain 2.4 and even boostify it in the process. I'm already quite familiar with it. But I'm not sure there's enough time to do it, let alone maintain and support it. I'm still hoping Maxim changes his mind. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Malte Clasen wrote:
Jose wrote:
On 1/24/07, Bjørn Roald <bjorn@4roald.org> wrote:
Which may allow use of AGG 2.4 code in Boost under the boost license. Any thoughts on that?
But 2.4 is an old release, so it looks like it wouldn't be a good idea to aim for serious AGG integration
It's not current, but far from being outdated. There seem to be several people (including me) who stick with it because of licensing issues. I'm quite sure that a branch starting at 2.4 could be successful from a user's perspective, considering the comments on the agg mailing list. However, without a motivated lead developer, this is going to be a dead end, since there's currently no AGG development community that could switch to the Boost branch. But if someone wants to start working on this, I'd say this is the time to do so.
I agree. 2.4 is a good release. It's a good point for branching. I had high hopes for some work on antigrain, views and rendering and GIL. I did a quick demo on integration when GIL was reviewed.
It's possible to fork Antigrain 2.4 and even boostify it in the process. I'm already quite familiar with it. But I'm not sure there's enough time to do it, let alone maintain and support it. I'm still hoping Maxim changes his mind.
I strongly agree with you. The way things seems to me from lurking in the agg mailing list is that Maxim has some clear motivation for the license change. 1. Continue to allow general "free" access to AGG 2. Make those who intend make AGG "their own" product pay him a bit for a different license I think this is only fair. Antigrain Geometry 2.4 is as many have said, a *great* gift to the community. And AGG >= 2.5 is "free" for the GPL community. The fact that Maxim clearly don't want others to take all profit for his great work is easy to understand. I think his motivation is primarily to make a decent living from his product. This will allow him to continue using his time on what he clearly is talented and skilled at. In itself that is a very good thing. If he is to change his mind about the licensing, as well as how to contribute to the community, I think it is reasonable that those that have ideas (proven by experience), or other means that can convince him, come forward and bring their information to him. Now is the time. It may be best to discuss this privately with Maxim, see contact information on http://www.antigrain.com/mcseem/index.html ---- Bjørn
Greetings On 1/25/07, Bjørn Roald <bjorn@4roald.org> wrote:
It's possible to fork Antigrain 2.4 and even boostify it in the process. I'm already quite familiar with it. But I'm not sure there's enough time to do it, let alone maintain and support it. I'm still hoping Maxim changes his mind. I think his motivation is primarily to make a decent living from his
Joel de Guzman wrote: product. This will allow him to continue using his time on what he clearly is talented and skilled at. In itself that is a very good thing. If he is to change his mind about the licensing, as well as how to contribute to the community, I think it is reasonable that those that have ideas (proven by experience), or other means that can convince him, come forward and bring their information to him. Now is the time.
I on occasion follow the Haiku project (http://www.haiku-os.org) which is small (team wise) but ambitious in creating binary compatibility with BeOS, and remember reading about them using AGG and a quick google confirms. Another quick google only gave me one reference to a mention of license change, and it dealt with trying to negotiate with the author, and that was back in October. I have no clue if they have come up with any solution, but if a fork is done, I would hope that you could get some collaboration going on with some of their developers. Ed Page
participants (7)
-
Bjørn Roald -
Edward Page -
Joel de Guzman -
Jose -
Lubomir Bourdev -
Malte Clasen -
Tom Brinkman