Re: Heated agreement? (was) Re: Canvas shortcomings
- From: Nathan Hurst <njh hawthorn csse monash edu au>
- To: Mark <jamess1 wwnet net>
- Cc: Martin Sevior <msevior mccubbin ph unimelb edu au>, Owen Taylor <otaylor redhat com>, Lauris Kaplinski <lauris ximian com>, Havoc Pennington <hp redhat com>, Gustavo João Alves Marques Carneiro <ee96090 fe up pt>, gnome-devel-list gnome org
- Subject: Re: Heated agreement? (was) Re: Canvas shortcomings
- Date: Wed, 20 Jun 2001 10:32:50 +1000 (EST)
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 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.
The problem with using postscript is that you need to run an interpreter,
which is going to add many further security issues to X. postscript's
rendering model, OTOH, is quite nice. PDF 1.4 is even nicer. 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.
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?
2. what will we be able to do efficiently in hardware in the future?
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)
5. How important is portability?
6. Can we merge our work with our free software tools? (such as Mesa,
ghostscript)
7. Which commercial systems should we copy from? (such as NeWs,
postscript, Quickdraw{, GX}, Win32 graphics subsystem)
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)
9. How easy should it be for the 'user programmer' to access pixels? to
composite pixelmaps on the screen?
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?
njh
p.s. is there any simple XRender demo code around?
p.p.s sorry if you get this message twice.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]