Re: Comments on Artlib backend

[Alexander Malmberg]

> 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