[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on Artlib backend
From: |
Alexander Malmberg |
Subject: |
Re: Comments on Artlib backend |
Date: |
Tue, 27 Aug 2002 14:03:53 +0200 |
> Hi Alexander,
>
> I looked at your great backend based on the libart library. I am quite
> impressed by all the composite operator code, as all the other backends
> have been missing this and the way you implemented it looks like it
> could be reused for most of them. But before we can do this, a few
> questions must be cleared:
>
> Currently some of the files are still copyrighted to you, as far as I
> understand it this will be a problem for GNUstep. (Adam, please correct
> me if I am wrong here)
I've fixed this in cvs (I think, if anything more is necessary, just
tell me).
> The current file structure is a bit confusing to me. The ArtContext and
> the ARTGState share one file, but should be separated into two.
I've started splitting things up, and this should be in cvs by now.
> And
> blit.m includes itself multiple times, whereas this could easily be
> replaced by a new file that would include blit.m.
If that is considered 'cleaner', I can change it to do that. What is the
preferred extension of such an included file?
> There is an implementation of DPSarct in ARTContext.m, could this be
> used as the starting point to implement this method in GSGState?
It's implemented using DPSlineto and DPSarc, so it could be used as is.
I'll move it to GSGState.
> And how
> about the method appendBezierPathWithArcFromPoint:toPoint:radius:?
Probably.
> There is some code duplication. The methods for NSBitmapImageRep could
> be moved to x11, the best solution would be to move the whole file
> XGBitmapImageRep.m to this directory, renaming it in this process. Than
> this code could be used by all the X based backends.
The code there depends more on libwraster than on X, but if that's no
problem, it'd be cleaner to move it to x11/.
> Currently ARTGState keeps its path in user space (Which is already
> stated in the code as being a problem). As far as I understand this, it
> is done to allow for the dash to be adjusted, but this is currently not
> used. So I dont see any reason for this and we could use the GSGState
> path methods instead of specific methods here.
The main reason is to handle arcs properly. Arcs need to be constructed
in user space and then translated, so a circle looks like an ellipse if
user space is scaled differently along the axises. ARTGState handles
this correctly; GSGState doesn't. Dashes and line widths need similar
treatment, and ARTGState doesn't do this perfectly currently (due to
lacking libart support). It does handle uniform x/y scaling correctly,
though.
> I like the idea to have a method to get the current path. This propably
> is the only way to implement the NSBezierPath glyph methods. Could we
> move this to GSGState?
At the time, it was just a quick hack to help me debug a few things, but
we already have a method to get the current ctm, so it is a reasonable
thing to add.
> What I did not understand at all is what the RDS environment is and how
> this backend should be compiled for it.
rds is a _highly_ experimental display server (replacing x11/), so you'd
configure it with --enable-graphics=art --enable-server=rds. There is a
version at
http://w1.423.telia.com/~u42308495/alex/backart/rds-0.0.1.tar.gz , but
note that this is _highly_ experimental; I'm not interested in feedback
or bug reports or comments about how ugly the code is, I already know
about all that :). (There's a good chance that it won't even work with
current cvs.)
Anyway, rds used DO to communicate the the 'real' display server (the
one in the tarball uses opengl; directfb would also be interesting).
-art renders to shared memory buffers that the display server displays
somehow. There are a couple of points do doing this, but the experiment
showed that it's possible, but not with my current opengl drivers.
I'm not working on it currently, but I might pick it up again later. If
anyone else wants to continue experimenting with it, you're very welcome
to do so.
> I hope that at least a few of this questions, statements make sense and
> help us to simpler and more powerful backends.
>
> Cheers Fred
- Alexander Malmberg
- Comments on Artlib backend, Fred Kiefer, 2002/08/26
- Re: Comments on Artlib backend,
Alexander Malmberg <=
- Re: Comments on Artlib backend, Alexander Malmberg, 2002/08/27
- Re: Comments on Artlib backend, BALATON Zoltan, 2002/08/28
- Re: Comments on Artlib backend, Alexander Malmberg, 2002/08/28
- Re: Comments on Artlib backend, Richard Frith-Macdonald, 2002/08/28
- Re: Comments on Artlib backend, Alexander Malmberg, 2002/08/28
- Re: Comments on Artlib backend, BALATON Zoltan, 2002/08/29