Adam Jackson <[email protected]> writes: > Stored procedures in X11 don't win you much; very little of the > workload is blocked on round trips.
NeWS provided this, and the result was two classes of applications -- those implemented entirely within the window system server and those implemented entirely on the other side of the network link. Attempts to build hybrid applications were stymied by the complexity of constructing yet another network protocol, and the problems of working in two different development systems at the same time. One can see places where stored procedures make a lot of sense in the related area of graphics; GLSL has been a huge improvement over the non-Turing versions of OpenGL. Within the window system, where interactions are generally bounded by human response times, it's just been easier to make the link fast enough that it just doesn't matter. > I'd much prefer to identify the actual performance issues with the > protocol and add extension requests to fix those. PropertyNotify, for > instance, will get sent for any property change on a window (even for > properties you don't care about), and includes only the atom naming the > property and not its content (which you probably want). So not only > does it make you round-trip, it also causes a thundering herd. I thought we'd seen a proposal to add a new Fixes request that selected for specific property events; that would certainly be easy to add. > In general the lesson from X11 has been that rendering API and > complicated logic in the server was a mistake; Using an enormous API like OpenGL in every application isn't an obvious win though; the cost of setting up and maintaining all of that state is still non-trivial, especially for text rendering. The notion of having a suite of small utilities that work together to build a desktop environment relies on a light-weight graphics environment. Not that I'm suggesting that the X rendering model is actually good in any aesthetic sense, just that it takes almost no memory or time in the application. I don't know the right answer here, all I know is we've got two systems today which each solve a subset of the known issues. > that once you hit 60fps fairness is more important than throughput; > and that requests should be asynchronous and execute in small, bounded > time. The only non-trivial operations in X are ridiculous rendering requests; so we need to execute those asynchronously with respect to other X requests. Doing rendering entirely within the client is one solution, one wonders if there might not be others? -- -keith
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
