Re: interesting article on XFree86 speed

Allen Akin <[email protected]> writes:

> On Thu, Oct 24, 2002 at 10:20:18PM -0400, Owen Taylor wrote:
> | 
> | There are two latencies:
> | 
> |  1) Time from mouse motion to when drawing starts
> |  2) Time from drawing starting to drawing finishing
> | 
> | I'm mostly considering the second; double buffering can't eliminate
> | it if drawing is being done by multiple entities...
> 
> In the 3D world, we've traditionally handled that by putting multiple
> windows into a "swap group."  No window in the group will be swapped
> until swap commands have been issued for all the windows in the group.
> The groups can be built and destroyed as needed.  In the case of window
> management operations, you'd need to be sure that the window manager
> creates the swap group for the frame and content areas before passing
> the redirected configuration and exposure events to the apps, to avoid
> a race.

Yes, a facility like this was basically one of the suggestions 
in my original mail.
 
> | Clearly if the latency is small enough it doesn't matter;
> | but that "small enough" is pretty small. I'd estimate it
> | at 30-40ms for the first example above, and 10-20ms for the 
> | second. (No science claimed for those numbers; based on personal 
> | experience and back-of-the envelope guesses of number-of-pixels 
> | at a particular motion speed.)
> 
> To some of us, 10-20ms seems like a generously long time.  If you're
> building a game or a simulation, you always need to be able to render a
> full complex scene in one frame time (call it 12ms these days).
> 
> Looked at another way, last spring's generation of graphics cards have
> *textured* fill rates in the 400 to 800Mpix/s range (for 32-bit pixels).
> 10ms gives you time to write 4 to 8 Mpix, which should be massive
> overkill for, say, filling exposed areas with antialiased text (glyphs
> stored as textures) during a window reconfiguration.  Even graphics
> cards of several generations back should give you enough horsepower to
> redraw the entire screen once in 20ms.
> 
> Hence the question I asked in the previous note.  I'm wondering where
> all the time is going.  Do the toolkits need some improvement in the way
> they handle exposures, are we increasing latency too much by buffering
> too many commands between client and server, or is it something else

In general something like a dialog window is going to resize and
repaint prettty well .... there may be a little bit of jitter
and trailing exposes, because of the lack of synchronous exposes.
But it is going to look pretty smooth. 

Where you get into trouble are apps like Acroread, Mozilla, a paint
program with a lot of layers, a word processor ... where there are
significant computations involved in the bits displayed on the screen,
and when resizing, where a resize can involve a lot of recomputation.

There are definitely improvements that can be done in increasing
rendering _speed_ in XFree86 ... mostly just getting hardware
acceleration for the right parts of render and better video memory
management.. protocal latency isn't much of a problem that I've
noticed. 

But I think the real work is in improving the smoothness of a complex
update involving multiple applications.

There is some work that can be done in terms of getting better
motion compression for mouse events, but that is mostly a toolkit
level thing... in most cases having X send all the events and
letting the toolkit sort things out should be OK.

> | Application writers don't generally write their apps to
> | be able to repaint in 10-20ms...
> 
> Or perhaps it's the apps, rather than the toolkits, that are causing the
> problem?  But if so, they still seem to be using a lot more time than I
> would have expected.  Maybe it's mostly the lack of synchronized
> double-buffering that causes the visible glitches?

That's the big thing -- not updating the frame and the contents together
gives you temporarily wrong areas visible and jitter between the
frame and window contents.

If you imagine something like an opaque resize of a text widget, you can 
see why 10-20ms can be very demanding ... resizing a window 1 pixel
wider might involve a complete relayout of a megabyte of text.

Now, by using techniques like incremental layout, you can hide that
relayout time, but that requires complex application design and
a high level of sophistication.

Regards,
                                        Owen