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 <[email protected]> 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 <[email protected]> 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 >> > _______________________________________________ >> > [email protected]: X.Org development >> > Archives: http://lists.x.org/archives/xorg-devel >> > Info: http://lists.x.org/mailman/listinfo/xorg-devel >> >> >> >> -- >> Jasper >> _______________________________________________ >> [email protected]: X.Org development >> Archives: http://lists.x.org/archives/xorg-devel >> Info: http://lists.x.org/mailman/listinfo/xorg-devel >> -- Jasper _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
