|Subject:||Comments on Artlib backend|
|Date:||Tue, 27 Aug 2002 02:00:48 +0200|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204|
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)
The current file structure is a bit confusing to me. The ArtContext and the ARTGState share one file, but should be separated into two. And blit.m includes itself multiple times, whereas this could easily be replaced by a new file that would include blit.m.
There is an implementation of DPSarct in ARTContext.m, could this be used as the starting point to implement this method in GSGState? And how about the method appendBezierPathWithArcFromPoint:toPoint:radius:?
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 beep method on ARTContext looks like a left-over from a previous version.
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.
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?
What I did not understand at all is what the RDS environment is and how this backend should be compiled for it.
I hope that at least a few of this questions, statements make sense and help us to simpler and more powerful backends.
|[Prev in Thread]||Current Thread||[Next in Thread]|