Re: Heated agreement? (was) Re: Canvas shortcomings

[Mark <jamess1 wwnet net>]

On Wed, 20 Jun 2001, Nathan Hurst wrote:

> On Tue, 19 Jun 2001, Mark wrote:
> 
> > On Wed, 20 Jun 2001, Martin Sevior wrote:
> > 
> > > It seems to me that we're in heated agreement that there should be a set
> > > of virtual primitive functions that call arbitary backend graphics
> > > contexts. Right?
> > 
> > Well, I posted some messages too, so I don't know if the debate was
> > limited to three points of view in total agreement.
> > 
> > I'm not sure why this is on a public list. Why don't you three e-mail each
> > other and figure out a solution. The general feeling I get from this
> > discusion is one of insolence and volutary ignorance.
> 
> It is important that it be discussed on this list so that others, who are
> interested - yet don't feel they have something to contribute yet, can be
> involved in the decision making process.
>

I wasn't sugesting that, just expressing my frustration. His e-mail was
written as if only three people were discussing the subject. And no one
until now has adressed using display postcript, the work already done on
the two display postscript interpreters has not been discussed.
 
> I guess now that I've joined the debate, I think that we should implement
> a more powerful rendering system using XFree as a base(In particular,
> XRender).  XRender provides a trapezoid renderer which could be driven by
> libart's SVP (although the libart SVP code needs some work to get
> numerical stability still).
> 
> I would suggest that we put SVP rendering into the XRender extension.  We
> then can do pretty much anything that pdf 1.4 can do, but with the
> significant speed advantages that a presorted polyline set gives.

As I understand the SVP (sorted vector path) is an optimization for
scan-line rendering. Does it have good properties for teslation too? Also
XRender is meant as an abstraction of acceleration present in hardware, so
maybe that should be done as an extention? But then perhaps it might be
worth just improving the DPS extention. 

> 
> The problem with using postscript is that you need to run an interpreter,
> which is going to add many further security issues to X.

I can't see any additional security risks from X, the code is limited to
displaying graphics.

> postscript's
> rendering model, OTOH, is quite nice.  PDF 1.4 is even nicer. 

They are the same, PDF uses the postscript 3 drawing model. PDF is
designed for a better document distribution, and includes features for
structuring the document and adding interactive features.

> Having said
> that, I agree that being able to reuse macros makes postscript quite nice,
> but I think that a user-space library to handle the macros will be just as
> beneficial (and in 5 years, when we are all using this, and we all use
> lauris' mandelbrot macro in all our programs, we simply move the
> mandelbrot generator into custom hardware and update the library.
>

DGS is a user-space postscript interpreter as I understand. If a
user-space library is prefered instead of a server extention, DGS is
definently an option.
 
> Ok, now I've had my rave, here are some points to think about and talk
> about:
> 
> 1. what can we do efficiently in hardware on most machines?

I'm not qualified to answer this, but what I've seen of the MacOS, which
runs on modern hardware, is quite impresive. We could implement rendering
hints, so the performace is good on lower end machines. These render hints
would specify whether to use an anti-aliasing techique, how images are
scaled, ect.

> 2. what will we be able to do efficiently in hardware in the future?

I'd say look at a new Mac which runs Mac OS X. 

> 3. where can get significant performance enhancements by moving into
> X(/the kernel)?
> 4. how important is low userspace <-> X traffic, and how important are
> round trips? (keep in mind that most people run most software locally, and
> that networks are getting faster much more quickly than X evolves)

That is probably true that most people use X locally, especially for
Gnome. Display postscript looks ideal for a networked display
server, and I don't think it would hurt the user of a local display
server.

> 5. How important is portability?
> 6. Can we merge our work with our free software tools? (such as Mesa,
> ghostscript)

Mesa is an OpenGL library and not really relevant. DGS and DPS both use
ghostscript. Building on their work I think would be very benifitial to
free software. GNUStep is a project that is based on DGS, and think this
might be a good point of colaberation between Gnome an GNUStep. There is
also libart, which you are familiar with. I'm not sure exactly how that
would fit in for a higher level library. You'd probably, as you said, 
build acceleration into it. And then maybe implement higher level access
like postscript, or a java2D-like API. I'm not sure the benifts to this
over building acceleration into DPS and improving it.

> 7. Which commercial systems should we copy from?  (such as NeWs,
> postscript, Quickdraw{, GX}, Win32 graphics subsystem)

Mac OS X, NeXT, and NeWS get my vote. The all use a variant of the
postscript model.

> 8. Considering the fact that print-ready is quite different to screen
> imaging, at what point do we want to provide printer transparency? (I 
> can't see the value in putting lots of work in so that we can run gnome on
> a colour laser printer)

Postscript will make "print screen" really mean something. In general
though it is where you want to place the abstraction. Postscript, for
instance, is device independent, all graphics are done in real world
measurements. You can still make decisions at the pixel level provided you
have a function pixels_per_unit ().

> 9. How easy should it be for the 'user programmer' to access pixels?  to
> composite pixelmaps on the screen?

With the X model, it's not that easy, unless you have a shared piece of
memory. The gimp would certainly need something like that, since it deals
directly with pixels.

> 10. Is backward compatibility important, or can we assume that the
> existing X driver for gdk will be enough for most users?
> 11. Is it worth spending hours talking about this if no-one is actually
> going to implement anything, or use it?
>

I've already pointed to some efforts with display postscript. Also you
have libart which looks techincally good, but is probably limited by lack
of acceleration.  DPS and GPS lack acceleration too, so they would benifit
from Render too.

> njh
> p.s. is there any simple XRender demo code around?

Render is not finished that I know of.