Re: Snappy GUI response

On Thu, 2003-07-03 at 16:34, David Jeske wrote:
> On Thu, Jul 03, 2003 at 12:52:52PM -0700, Mark Vojkovich wrote:
> >    This is because people writing X applications (and particularly 
> > X toolkits) have little understanding of graphics performance issues
> > in the X-Window system.  They say they do, but the results (slower
> > and slower toolkits every year) imply that they don't.  Most of
> > these problems lie in the continued failure of toolkits to reduce
> > the round trip communication between the client and the server.
> 
> Is there any X-benchmark which shows that the performance of an
> application under X can come close to the performance of an
> application under Windows when written "correctly"? 
> 
> IMO, a bigger contributing factor is that the X design does not have
> application performance as its number one objective, and the resulting
> compromises are hard to make. X was designed when networked terminals
> (Xterms) hooked up to central servers (mainframes) was an important
> configuration. It's hard to let go of those roots.
> 
> As an observer, it looks to me like the X priorities are:
> 
> 1) maintain X network-protocol compatibility
> 2) maintain xlib library compatibility
> 3) improve performance through optional extensions (dga,etc)
> 4) avoid letting the X-server get huge through big changes to 
>    the display model

Well, 1) and 2) aren't "priorities", they are hard requirements.
But there is absolutely no reason they should affect performance
work. X is a nice extensible framework, there is no reason to
make incompatible changes.

> It would take a monumental shift in the mindset of the entire concept
> of what X is to change this. Everyone working on X everywhere would
> have to agree that being high performance is the most important goal,
> and that anything and everything would be changed which got in the
> way. 

Nah, just need to work on getting a few real tests of performance -
put a number on "snappy" - and work on optimizing that. Whatever
is being complained about is much more likely a kernel/app issue than
an X issue anyways.

> If you want to improve the performance of X, port (or replicate)
> winbench, and drop priority #1 above. Get ready for a rude awakening
> when you see the first scores, and take as your ultimate goal to have
> this winbench port rival the performance of Windows winbench. I bet if
> you talked to the right people at VeriTest/PC Magazine they would let
> you help them port the original code.
> 
>   http://www.veritest.com/benchmarks/winbench/winbench.asp

The kind of graphics benchmarking that benchmarks like winbench usually
do - how many lines can you draw a second, etc -  is pretty irrelevant
to what's being discussed here.

What really is interesting is the lag from when the user clicks the
mouse button to when the system finishes responding to it (by drawing
the menu that pops up, or whatever.

Regards,
					Owen