[Top][All Lists]
[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 00:46:38 -1000 |
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