[Top][All Lists]

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

Re: [xougen] Regarding server side widgets

From: >> G-LiTe /
Subject: Re: [xougen] Regarding server side widgets
Date: Fri, 29 Aug 2003 15:47:11 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030818 Thunderbird/0.2a

address@hidden wrote:

On Thu, Aug 28, 2003 at 09:01:44AM +0800, Craig Ringer wrote:

hello again

What about better performance ?

When we someday find a way for doing some important things much better
(i.e. uploading huge textures to the server or working with something better than unix sockets), so why should we refuse to do that ?!
Of course the normal X protocol has to be supported (at least as fallback)
on both sides, but if both sides can speak something better, they really
should use it. Those things do not belong into the client code, and should
be completely hidden behind it.
A better way than unix sockets means using another protocol which shouldn't
be that hard. Implementing widgets server side is totally different level.
You're talking about the X11 protocol there and not what the X11 protocol
works on top of and I don't think it'll increase performance that much;
merely reduce flexibility.
If we change the protocol then it won't really be an X Server anymore.
Adding a different protocol means bloat and sounds silly to me.
Remember the unix philosophy? Write one good app to do just one thing.
(Do you use KDE or emacs by any chance? Pun intended, haha. Sorry I'm just
another weird gnome advocate: ignore this. ;) )

If we can put evrything into extensions, than its okay. but perhaps
someday this will not work anylonger, so we should be open for that.
Afaik adding new protocols shouldn't be that hard. Could be wrong.
Completely seperating the code as dynamic libraries or so sounds, again,
rather silly to me; I doubt the lower level protocols X11 works on top
of will become proprietary or closed or anything: they're standards.

I also dont, so I'm friend of the multiprotocol variant - so we _can_
put really evryting into the display server.
If I understood it right, 3D support is currently only supported local
(seems like somehow bypassing the Xserver ?). This should also work
remotely. Also I'd like to see an mpeg streaming support directly in the Xserver, since many modern cards have hardware acceleration for that.
MPEG streaming is possible, I think. But 3D _really_ can't be done over a
network, unless you write a wrapper library orso to handle it.
Using 3D means directly writing to video memory and it just won't work
over a network. Simple as that. Applications using opengl in X don't
even do it using the X11 protocol.

I've expressed interest previously in built-in VNC support for the X server... but for the X server to provide a VNC server (note overloaded meaning of server) that can be used to view the X server's frame buffer remotely.
This will be an multiprotocol server, you know that ?
And that is why I'm against it. I'd rather provide the functionality to
applications, ie. the XDamage extension sounds like a very good idea to me.

I can't claim to know overly much about Xlib, but from what I've been hearing it's a bit of a pain to code against. So perhaps there's an argument for an "xlib2" or something - but that need not break or even
Are you talking about an new lib or an new interface ? That's completely
Already in the works as somebody else said: XCB.
See xwin's / freedesktop's wiki.

There are a lot of cool possibilities with X11, but it strikes me that the real issues right now are not with the protocol or such, but with driver availability and the difficulty of getting updated drivers for XFree86 as things stand. Xouvert can improve that by providing separately packaged drivers, and IMHO that'd be an important step.
ACK. The whole distribution should be splitted into smaller packages.
So we i.e. have some Xcommon, Xserver-framework, Xserver-card1, Xserver-card2, ..., Xserver-mouse, ...
That's impossible. All these components use the X11 protocol and it's
thus much easier to have it handled by a single application.
Seperating the backends is a different thing though, and I have no problem
with that.

> G-LiTe /

reply via email to

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