gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal /Inquiry of using Cairo as the one and only....


From: Chad Hardin
Subject: Re: Proposal /Inquiry of using Cairo as the one and only....
Date: Thu, 22 Jan 2004 01:33:34 -1000

Actually just forget the whole idea, I realize now it was quite a dumb one! :-)

At least I'm thinking about these things though, can't blame me for that. :-)

Thanks for putting up with me!

Chad


On Jan 22, 2004, at 12:46 AM, Chad Hardin wrote:

another discalimer: It was 12:30 am here and I couldn't sleep and I was quite tired....

I didn't actually mean GSDisplayServer. What I meant was GScontext and friends.

What I was trying to say is to propose putting the cairo stuff in gnustep-gui, and not as a new backend.

Ok, now let the bashing really commence, I learn well that way...

Chad


On Jan 22, 2004, at 12:23 AM, Chad Hardin wrote:

(Disclaimer: I'm not try ing to start a flame war or upset anybody, this is just a suggestion which I think we could talk about...)

***Intro***

As many of you know, I've been working on the directfb backend for GNustep for a few weeks now. I'm only about 60% done with the server side of the backend, but naturally I'm looking ahead to how to do the graphics side.

I've been leaning toward using Cairo, which used the be the Xr extension, and is extremely postscript like. It looks to me that Cairo would be a perfect match for the DirectFB backbend. Maybe it would need some work with the text rendering, not sure yet though because I actually haven't had a chance to test Cairo's output of text yet. i'll get back to you all on that.


**Here's my idea***

Anyhow, while thinking this through I realized something: Perhaps Cairo can be used the sole rendering system for the entire backend infrastructure. What I mean by this is that it may be possible, and best in the long run, to put the Cairo stuff directly in GSDisplayServer. GSDisplayServer would then take the brunt of the graphics work and become a highly usable subclass for ALL the backends.

Since Cairo can do it's drawing to memory, GSDisplayServer can handle the actual drawing for Buffered and retained windows (do non-retained windows even have a purpose in today's world?) in a very generic fashion (ARGB). Note that the last time I looked, OS X (duck) doesn't implement non-retained windows.

Then, all the differing backends (x11, win32, directfb) would have to do is take the memory area from GSDisplayServer, which contains the windows graphics, and use that for whatever display system it's using. A simple blit.

The advantages are obvious. Each backend would use the exact same code for rendering. Each backend could be reduced in size and complexity tremendously. And each backend would have an awesome, Postscript like imaging system for free.

Cairo is not device system dependent, it only has one external library it depends on (libpixman, which is also device independent). Cairo can output to memory, postscript, and X11 (x11 can be disabled at compile time, so you end up with a nice, very generic rendering system). I don't think having the GNUstep build depend on it would be big problem.

I realize that a LOT of hard work has been put into the X11 backend, and by no means do I negate that, it works very well. I also realize that a switch to a Cairo based GSDisplayServer would mean a whole lot of this hard work would become obsolete. Trust me, I don't take that lightly. But switching to Cairo may the best way to go in the long run because we'd have a *very* nice rendering system available for all the backends, including Win32.

This is just my idea, I don't claim that it is something which HAS to be done now or at all. But I do think it's something that can be taken into consideration and we can talk about.

Ok, let the bashing begin.... :-)


Thanks,

Chad





_______________________________________________
Gnustep-dev mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/gnustep-dev



_______________________________________________
Gnustep-dev mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/gnustep-dev





reply via email to

[Prev in Thread] Current Thread [Next in Thread]