Re: Does KDE really support XRender?
On Sun, Oct 12, 2003 at 10:05:42AM +0200, Anders Ellenshøj Andersen wrote:
| Well I concede that this depends on what you are used to. A while back
| I was a die hard Amigan, and from Amigas I am used to the mouse
| pointer being a hardware sprite.
XFree86 uses hardware mouse cursors on graphics hardware that supports
it. I can't imagine that the pointer movement would be any different to
on other operating systems, although it is possible that I'm just not
sensitive to the jumpiness that you describe.
| I think, as has also been mentioned by others, that this is coursed by the
| server not buffering enough graphics. The problem is that, as far as I know,
| the X protocol prevents the server from doing this.
It is possible that buffering window contents would make window movement
smoother in cases where you're dragging a window over a non-root window,
but given that the memory cost would be prohibitive on some systems and
that other windowing systems /aren't/ doing this, I don't think it's the
right solution.
| I remember reading somewhere, that the window manager decorations and
| the window contents was, by design two entirely different entities and
| could never be rendered in one pass.
They require two different programmes to communicate with the X server.
But when you're just moving windows around, the window contents aren't
re-rendered - they're just blitted from one place to another. Then the
window behind it is sent an "expose" event from the X server and has to
redraw itself. (I believe that an except is the case of the root
window, where the X server knows the window contents.) Perhaps it's the
efficiency of this redraw step that needs to be improved somehow?
The initial rendering or the redrawing of a window does involve both the
WM and the app redrawing their respective bits of the window. Can you
suggest a way of doing things such that this /isn't/ the case? To the
best of my (limited) knowledge, Windows also has separate processes
involved in the drawing of the window borders and the window contents.
(BTW: I'm not denying that X has problems or implying that you're just
imagining your sluggish window dragging. I'm just suggesting that this
isn't necessarily for the reasons that you think it is.)
| When I say doesn't work over network, I mean at adsl like speeds.
| 1024kbit and below. Apps that doesn't work over network in my
| experience? Mathematica, IDL.
Hmm. I have a friend that uses Mathematica with ssh forwarding and
compression from Uni to his 256/64 DSL line. While I haven't seen it
myself, he implied that it worked tolerably quickly.
| IDL kind of works, but data visualisations are often buggy. As far as I
| understand it, the problem is that each application (or gui toolkit) has to
| take all kinds of different hardware into consideration when doing it's
| rendering,
I don't think that's the case. The X server and Xlib should abstract
all of that away, so the application doesn't know or care whether it's
running locally or remotely. (I'm not saying there aren't buggy apps
around, though. I believe at one point, Mozilla plugins didn't work
properly over a remote X session, ferinstance.)
| the application has to know how to handle color maps and stuff.
That works the same way remotely as locally. But it wouldn't surprise
me if X's colour map handling sucks... :-)
| There is too much stuff that the server really should do, that it doesn't do.
| I welcome efforts like fresco or Y, but unfortunately the momentum never
| seems to want to keep these projects going.
Yes. I'm particularly fond of the idea of integrating the toolkit into
the server. This could improve performance over a network, and more
importantly, give apps something vaguely resembling consistency.
(<rant>Except for Mozilla and OO.o which both insist on doing everything
themselves regardless of what OS they're running on. Cross-platform
coding done the brain-damaged way.</rant>)
People would think it ludicrous if GTK and Qt apps had different borders
and title bars because window management was handled on a
per-application basis. Handling of menus and buttons and other widgets
needs to be abstracted out too.
Cheers,
Cameron.
Reply to: