Nested procedures into X12

[Peter Hutterer]

On Wed, Jun 17, 2015 at 02:05:59PM -0700, Jasper St. Pierre wrote:
> For context, when we receive a MapNotify from the server, we have a
> number of round-trips with the server.
> 
> First, there's the XGetWindowAttributes. It would be convenient to
> have that along with the MapNotify, but not really a big deal.
> 
> We implement our own XCB-style async XGetWindowProperty (which we
> should probably replace with actual xcb these days), so that's one
> round-trip.
> 
> There's also the round-trips with setting up decorated windows
> (InternAtom and other things that happen on the first window).
> 
> ... but this is dwarfed by XIGrabKeycode, which makes a total of 92
> round-trips for one window, to set up window keybindings. This is
> because the developers of XInput decided that they would helpfully
> return which masks failed to grab, instead of returning an error.

and how is this different? what do you when one of the 92 single requests
fails? either you ignore the error or you unroll and ungrab all previously
requested ones, right?

How is this different to doing the same when you have a mask that failed to
grab?

Cheers,
   Peter

> 
> And yet it's still fast enough. Eliminating roundtrips would be nice,
> but we should make sure we're eliminating the roundtrips that matter.
> 
> On Wed, Jun 17, 2015 at 12:44 PM, Adam Jackson <ajax at nwnk.net> wrote:
> > On Wed, 2015-06-17 at 10:50 -0700, Keith Packard wrote:
> >
> >> 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.
> >
> > From me, even:
> >
> > http://patchwork.freedesktop.org/patch/8050/
> >
> > I hadn't thought to also make it emit a generic event and include the
> > property value in that proposal.  Would be nice for pagers and window
> > managers though, since you end up needing a ton of _NET_WM_FOO on every
> > window.  (Admittedly metacity and descendents roll their own async
> > GetWindowProperty so it's only _one_ round trip, but.)
> >
> >> 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.
> >
> > I mean, sure, GL's not ideal, that's why they keep chopping stuff off
> > it, core contexts and GLES and soon vulkan.  But I'm pretty sure "we
> > put all this rendering stuff in the server because we didn't have
> > shared libraries" is a story I've heard from you.
> >
> > Should there be some common rendering API?  Yeah probably.  Should it
> > live in the presentation server?  Probably not, but the SI isn't built
> > like that.
> >
> >> 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?
> >
> > I'm not really interested in trying to split ridiculous rendering to a
> > server thread, if that's what we're talking about.  X's atomicity
> > requirements make that pretty gross.
> >
> > - ajax
> > _______________________________________________
> > xorg-devel at lists.x.org: X.Org development
> > Archives: http://lists.x.org/archives/xorg-devel
> > Info: http://lists.x.org/mailman/listinfo/xorg-devel
> 
> 
> 
> -- 
>   Jasper
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>