Nested procedures into X12

[Jasper St. Pierre]

One lets us submit all the requests in one go and get notified if an
error happens. The other requires us to synchronously ping-pong
to/from the server.

On Wed, Jun 17, 2015 at 5:06 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> 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
>>



-- 
  Jasper