Re: Proposal to deprecate Xlib backend
On 12/28/06, Hubert Chan [EMAIL PROTECTED] wrote: On Thu, 28 Dec 2006 00:38:18 +0100, Guenther Noack [EMAIL PROTECTED] said: [...] I could also imagine that a clear indication that xlib is deprecated may help people outside the GNUstep project. For example when looking at Etoile, there are at least the MultimediaKit and the XWindowServerKit which directly talk to X11 (MMKit displays the Mplayer window in a GNUstep window). For authors of projects like these two, it may be very helpful to know that they won't have to support xlib in the future. AFAIK, Etoile still needs to talk to X11 directly for those functions. They are mostly for things that the *Step API does not handle (e.g. switching desktops, embedding, etc.). I think people are talking about using X11 for drawing, not window and even handling in this case. So deprecating x11 backend does not affect the use of X11. Yen-Ju -- Hubert Chan - email Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
Yen-Ju Chen schrieb: I guess this is the reason why transparency does not work in Cairo backend: cairo backend draw everything directly on xwindow. In -gui, an image is often draw on a hidden window, then composite on the destination. Because cairo backend draw directly on xwindow first, it loses the alpha value. Then when it is composited to the destination, the transparent part becomes the background of the hidden window. I have a copy of cairo backend in Etoile project: http://svn.gna.org/viewcvs/etoile/branches/yjchen/etoile_back/ It basically draw on the x11/XWindowBuffer first as what art backend does. Therefore, it keeps the alpha value for composition. The modification is very little. You can check out README.etoile_back. A simple diff is sufficient to see the difference of source code. There are some minor issues here and there, though. Great, this resolves the transparency issue! I added your changes for this to the official GNUstep cairo backend. I did not take over your changes to x11, on which I need to take another look. You also have a change to add the freetype2 libraries and settings to the configuration. This should not be needed if cairo is configured correctly. Could you please type in pkg-config --libs cairo at a command prompt to see if this includes freetype or not? I also added you endianess change, hope I did get it correct. As you have the unbuffered code commented out yourself, I did not take it over. And the NSClipView change is clearly a hack. We need to resolve the actual issue behind it. With images now drawn transparent you will see that many images get flipped. I will have to take another look into the horrible compositeGState:... method to sort this out. If we are lucky the clip view issue will get resolved by that as well. The next thing to investigate will than be the text drawing, as the metrics seem to be wrong here. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
On 25 Dec 2006, at 14:59, Gregory John Casamento wrote: All, I've been thinking about deprecating the Xlib backend, so that we can focus more on Cairo. I have discussed this with Fred and I would like to know what everone else thinks about it. Depends what is meant by 'deprecate'. It seems reasonable to move away from it ... but Cairo is not ready yet, and the art backend seems to have its own problems. My impression is that art is a little better than xlib but harder to maintain (code less clear etc). I'm taking it on trust (Fred's judgment and yours) that Cairo is the way to go rather than improving an older backend ... I don't have the graphics knowhow to make a good judgment myself. I think very little time is spent on maintaining either art or xlib ... interaction with x window managers needing (and getting) more attention than the actual xlib or art rendering code, so it's not a big issue right now. However, we do need to make sure people don't waste time on development work for multiple backends ... so we need a clear policy for future development work (especially for any new volunteers). So, in terms of what people should be told to *use*, I don't think we should deprecate xlib until Cairo is more usable than it, but in terms of what people should do development work on, I would deprecate both xlib and art immediately. Once cairo is at least as usable (glitch-free, feature-full, and quick) as xlib and art, we should deprecate both old backends. I think backend development work should concentrate on cairo. If Cairo also works well in the mswindows world, we should probably concentrate on a cairo graphics engine for both unix and windows. For MacOS-X compatibility, would it be possible to do CoreGraphics in terms of Cairo for both unix and windows? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
Richard, The reasons behind the move to Cairo are as follows: 1) Cairo is being used by a number of other projects. It is very stable and well maintained. 2) Cairo has been ported to a number of other operating systems, including windows and has a large number of output targets. This way, Cairo would do much of the heavy lifting for us with regards to getting things to render acceptably on other platforms. I agree with what Richard is saying here as well. GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Richard Frith-Macdonald [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Monday, December 25, 2006 1:00:59 PM Subject: Re: Proposal to deprecate Xlib backend On 25 Dec 2006, at 14:59, Gregory John Casamento wrote: All, I've been thinking about deprecating the Xlib backend, so that we can focus more on Cairo. I have discussed this with Fred and I would like to know what everone else thinks about it. Depends what is meant by 'deprecate'. It seems reasonable to move away from it ... but Cairo is not ready yet, and the art backend seems to have its own problems. My impression is that art is a little better than xlib but harder to maintain (code less clear etc). I'm taking it on trust (Fred's judgment and yours) that Cairo is the way to go rather than improving an older backend ... I don't have the graphics knowhow to make a good judgment myself. I think very little time is spent on maintaining either art or xlib ... interaction with x window managers needing (and getting) more attention than the actual xlib or art rendering code, so it's not a big issue right now. However, we do need to make sure people don't waste time on development work for multiple backends ... so we need a clear policy for future development work (especially for any new volunteers). So, in terms of what people should be told to *use*, I don't think we should deprecate xlib until Cairo is more usable than it, but in terms of what people should do development work on, I would deprecate both xlib and art immediately. Once cairo is at least as usable (glitch-free, feature-full, and quick) as xlib and art, we should deprecate both old backends. I think backend development work should concentrate on cairo. If Cairo also works well in the mswindows world, we should probably concentrate on a cairo graphics engine for both unix and windows. For MacOS-X compatibility, would it be possible to do CoreGraphics in terms of Cairo for both unix and windows? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
Gregory John Casamento schrieb: Richard, The reasons behind the move to Cairo are as follows: 1) Cairo is being used by a number of other projects. It is very stable and well maintained. 2) Cairo has been ported to a number of other operating systems, including windows and has a large number of output targets. This way, Cairo would do much of the heavy lifting for us with regards to getting things to render acceptably on other platforms. I agree with what Richard is saying here as well. Looks like everybody agrees with Richard:-) So let's focus on the cairo backend for now and when it is finished deprecate xlib and art, but let them stick around for some time afterwards. Things to be done for the cairo backend: - Test with the latest cairo release. - Sort out copying from one cairo GState onto itself. - Get transparent images working. There is more, but these I remember from the top of my head. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
It's done then... Both XLIB and ART will be deprecated in the near future. We are shifting focus onto the Cairo backend. Development efforts on the backend should concentrate on getting the Cairo backend up and running. Once this is done XLIB and ART backends will stay in the repo for a TBD amount of time after which they will be moved to the obsolete folder. Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Richard Frith-Macdonald [EMAIL PROTECTED]; GNUstep Developers gnustep-dev@gnu.org Sent: Monday, December 25, 2006 5:57:04 PM Subject: Re: Proposal to deprecate Xlib backend Gregory John Casamento schrieb: Richard, The reasons behind the move to Cairo are as follows: 1) Cairo is being used by a number of other projects. It is very stable and well maintained. 2) Cairo has been ported to a number of other operating systems, including windows and has a large number of output targets. This way, Cairo would do much of the heavy lifting for us with regards to getting things to render acceptably on other platforms. I agree with what Richard is saying here as well. Looks like everybody agrees with Richard:-) So let's focus on the cairo backend for now and when it is finished deprecate xlib and art, but let them stick around for some time afterwards. Things to be done for the cairo backend: - Test with the latest cairo release. - Sort out copying from one cairo GState onto itself. - Get transparent images working. There is more, but these I remember from the top of my head. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
On 12/25/06, Fred Kiefer [EMAIL PROTECTED] wrote: Gregory John Casamento schrieb: Richard, The reasons behind the move to Cairo are as follows: 1) Cairo is being used by a number of other projects. It is very stable and well maintained. 2) Cairo has been ported to a number of other operating systems, including windows and has a large number of output targets. This way, Cairo would do much of the heavy lifting for us with regards to getting things to render acceptably on other platforms. I agree with what Richard is saying here as well. Looks like everybody agrees with Richard:-) So let's focus on the cairo backend for now and when it is finished deprecate xlib and art, but let them stick around for some time afterwards. Things to be done for the cairo backend: - Test with the latest cairo release. - Sort out copying from one cairo GState onto itself. - Get transparent images working. I guess this is the reason why transparency does not work in Cairo backend: cairo backend draw everything directly on xwindow. In -gui, an image is often draw on a hidden window, then composite on the destination. Because cairo backend draw directly on xwindow first, it loses the alpha value. Then when it is composited to the destination, the transparent part becomes the background of the hidden window. I have a copy of cairo backend in Etoile project: http://svn.gna.org/viewcvs/etoile/branches/yjchen/etoile_back/ It basically draw on the x11/XWindowBuffer first as what art backend does. Therefore, it keeps the alpha value for composition. The modification is very little. You can check out README.etoile_back. A simple diff is sufficient to see the difference of source code. There are some minor issues here and there, though. Happy holidays. Yen-Ju There is more, but these I remember from the top of my head. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
[EMAIL PROTECTED] wrote: I've been thinking about deprecating the Xlib backend, so that we can focus more on Cairo. I have discussed this with Fred and I would like to know what everone else thinks about it. I think the less backends the better, as its less code to maintain. That said, the cairo backend should function correctly out of the box i.e. there should be any need to go fishing around for anything other than cairo and cairo-glitz on the Internet. I believe this is already the case. Also, whilst we're on the topic of backends, is it worth trying to formalise and clean up the backend API? I don't know how other people feel about this, but to me it seems to be in want of some cleaning up e.g. set standards on the API instead of a mixture of old DPS commands and methods from various classes used to define the backend. Regards Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
