From: John P. Looney (valen at domain tuatha.org)
Date: Fri 06 Aug 1999 - 11:03:33 IST
On Thu, Aug 05, 1999 at 10:00:33PM +0100, Paul Jakma mentioned:
> On Thu, 5 Aug 1999, Caolan McNamara wrote:
> Im not so sure about that one, basically cache frequenty called
> sequences of routines and associate a single message id with them
> ? Send one request to "scroll window and all subsindows upwards
> by X", rather than multiple calls to move all the subwindows and
> the parent seperately ?
> exactly. very similar to display lists in GLX. Basically server side
> caching, but the client decides what should be cached. Also i was
> thinking to possibly allow parameters in some way, so that what's
> cached can be dynamically altered. eg to specify the length of a
> scrollbar. It should be fairly trivial for the X server to draw a
> longer scrollbar, provided the client told it how to when registering
> the scrollbar procedure.
This would work where the pipe to the CPU is much slower than the CPU
doing the work, or where the setup time to do an operation is quite long. X
setup, compared to OpenGL is a lot faster. Lists of things aren't going to
speed stuff up much. Most of the reason for the slowdown in X is moving &
creating big pixmaps (which the XShm thing seems to help a bit) and the
large quantity of events X generates & has to deal with - and it already
caches it. Caching is only helps when you get a lot of similar
events..stuff like hundreds of mouse moves, and X does cache those, to an
extent (and any decently written program should ignore mouse move events
while there are more on it's event queue, but anyway).
> Then there's also the cumulative benefit when there are many clients.
> The reduction in bandwidth used per client might typically be small,
> but the cumulative saving might just be enough to make a difference
> to that one app you're running that needs to move a lot of dynamic
> uncacheable data across the socket, eg netscape scrolling a long
> slashdot page.
I wonder ow this is done. Could it be that Netscape just says "move this
window 50 pixels up". If that's the case, it's just that the X server is
slow...the communication the the X server from Netscape is as fast as it
can be. Of course, what then happens is that ever window half covered could
get an expose event, and the app has to redraw the contents of the
window..so you get loads of different events, that do lines, images, fonts
I wonder could you do something like a display list, for expose events.
Say "do these operations when that window is exposed", and then store those
event sin the X server, for a period of time. Ponder. That would require
rewriting all apps to make use of it though.
> I read a DEC whitepaper about GLX, and one of the points was that
> with good use of display lists, loss of performance due to X overhead
> is negligible. But I'm only guessing - i have no real experience
> myself about where the real bottlenecks are.
That's on a slow video card. On a fast one, where the speed of X copying
the ouput of the GL engine to an X drawable X starts to slow down...which
the DGA stuff for GLX in XF86 4.0 is supposed to help.
What Caolan, and SGI are talking about are standard X apps, and how to
accelerate them without recompiling or rewriting. D11 sounds like the way
> I don't know any of the internals of gdk. I guess drawing a single
> button isn't too complicated. But i'm thinking more of complicated
> widgets, like menu's, scrollbars and such.
All a list is is a number of buttons, and a number of lines. When you are
writing a widget set, every widget is a load of lines, fonts, and images.
The amount of time your machine spends working out where to put theline
(which is what a widget set is), compared to drawing the line, means that
it's more important to accelerate the low level functions, than worry about
the high level ones.
I liked CaolansCISC/RISC Analogy - as long as the pipe from memory to the
CPU was slow, CISC was king. Direct rendering as opposed to
over-the-network is a lot faster...so for local stuff, widget set support
in the X server doesn't make sense.
-- Microsoft - the best reason in the world to drink beer
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:04:26 GMT