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. | 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? | 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? Allen _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
