[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Herbert Snorrason
Subject: Re: [xougen] Any plans to keep up with Longhorn?
Date: Wed, 12 Nov 2003 15:29:13 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031027 Thunderbird/0.3

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...

Attachment: pgpcfrx9d_i8L.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]