Re: [xougen] Any plans to keep up with Longhorn?

[Herbert Snorrason]

Maurizio Colucci wrote:
> I heard Longhorn is going to have vector graphics only, dropping 
> bitmaps completely. I was wondering if you have any plans to 
> counteract to (and possibly improve) those features.

> To be precise, every graphic element (which means every widget, 
> window frame, icon, text)
>
> 1. will be vector defined.
This is part of the X protocol. I must admit to not being sufficiently
familiar to answer. Depending on the particular instructions sent, it
might require either a full protocol change, or it could be done very 
easily. As Sun's NeWS seems to be lamented by many, I'll assume it's the 
latter.

> 2. will be rendered using the hardware primitives of the cards (3d 
> cards are mandatory in Longhorn, except for palmtops I presume). That
>  is, Longhorn will call the card's primitives to draw lines and 
> texture-mapped poligons, no software blitter.
Meaning a full reliance upon accelerated graphics functions. This would
require the server to use vector graphics. It can be done; it can even
be done in a way that might be portable to systems without the required
hardware functions. But it will require the server to use vector
graphics internally.

> 3. will support translucency (aka alpha-blending).
This has been done in X servers already, notably in XDirectFB. The real
question is this: Can the protocol plausibly do it?
I think it can. Support for the alpha channel is always spoken of as a
very real possibility.

> 4. will use z-buffering (don't ask me what for... futhermore 
> translucency and z-buffers don't mix well AFAIK).
Depth buffering and translucency don't mix? Why not? Unless I'm all the
more mistaken, they are totally unrelated. (And it's very possible that
I'm mistaken. I just wandered into this list by accident... ;)

> 5. will be dimensioned relative to the screen size, not to pixels, so
>  as to be invariant of the screen resolution. So, when you increase 
> the resolution, the bitmaps won't get smaller, and the lines will not
>  become thinner.
This comes for free with vector graphics.

> 1. these features will become a must in order to compete with 
> Longhorn. I can already hear Windows fans "linux has still bitmapped 
> graphics" adding to the already known complains.
Well, I don't think that would be accurate. It certainly is possible to
layer a vector system on top of X, without requiring a major change. (It
would, IMHO, be an ugly hack, but workable.) There is NeWS, which
although not popular, predates Longhorn by well over a decade. (Is it
approaching two?) And then there's always the counterargument that
Microsoft's just copying Apple. *AGAIN*. (Both NeXT and Mac OS X have
fully vector-based environments, in case you didn't know. Microsoft's
not the first. This is no innovation.)

> 2. web browsers will HAVE to supply those features (translucency and 
> vector graphics) in order to be XAML compliant.
And they seem to have been quite able to already. The thing is; the
browsers have their own rendering system: They can construct a bitmap
and send it to the windowing system. Lack of support for these features
in X itself has no real effect on browsers.

> 3. It seems to me that these features must be designed into the 
> architecture right from the start. For example, a dependency on 
> openGL seems mandatory.
And Xouvert is not a new design. It is, for better or for worse, X11R6.
Why would a dependency on OGL be mandatory?

> The KDE developers said it is not up to them, and that little is 
> possible unless the X server supports those features.
Possible? yes. Ugly hack? Yes. Would it be better to have support in X?
Yes. Is Xouvert going to implement that support? I certainly hope so. ;)

Odin -- Someone who really shouldn't be here...

pgpcfrx9d_i8L.pgp
Description: PGP signature