> 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
> etc.
>
guessing now, but i think it's the second way, ie line by line. which would
explain why it flickers so much.
> 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.
>
You'd add the support for this new X extension into the widget library
though, so no recompiling of apps. Just drop your new library in place, and
hey presto.
> > 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.
no, it was on a DEC PowerStorm 4DT, which is some kind of 3DLabs chipset,
either Glint or Permedia. So reasonably fast.
anyway, the balance between graphics card power and processor power shifts
backwards and forwards all the time.
> 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
> to go...
>
or maybe even add DRI support to Xm, qt and gdk. And have all your apps use
direct rendering. DRI isn't tied to OpenGL.
> 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.
exactly, so why not set it up once, and next time say 'draw it again, except
length=100'?
> 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.
true. you'd need to do a lot of profiling first to find out whether it'd be
worthwhile. Maybe the time'd be better spent on adding DRI support to gdk.
Then again maybe such an extension would be worth it for network speedups.
>> 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.
>
not actually support for server widgets, but rather support for saying 'draw
xyz again', rather than have to send the same set of X requests over and
over again.
> Kate
regards,
paul jakma.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
