Nested procedures into X12

Keith Packard keithp at keithp.com
Wed Jun 17 10:50:09 PDT 2015


Adam Jackson <ajax at nwnk.net> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20150617/10dabff5/attachment.sig>


More information about the xorg-devel mailing list