Hi, On 19 July 2012 21:33, Adam Jackson <a...@nwnk.net> wrote: > I think there's a combination of factors that pile on to make it worse than > you'd expect.
Oh no, we're talking about totally different things here. When I said with xkbcommon rather than xkbcomp, I meant that this thing: http://cgit.freedesktop.org/xorg/lib/libxkbcommon/tree/test/rulescomp.c#n70 takes 8.5-8.6 seconds to run on my laptop. Forking xkbcomp, feeding it a description on stdin, having it compile a keymap then serialise that to stdout, reading that back out in the server and then re-parsing it, is a total total disaster, I know. That's gotta be a lot more than 8ms. > Two, 8ms is half a frame, so if you _do_ hit it you run good chances of > missing a vblank, since you're starving out other clients. Also fixable, or > at least band-aid-able, if we're willing to rewrite the guilty XKB requests > to block the client, fire off xkbcomp, and complete it asynchronously. I don't think 8ms is that bad, to be honest. In an ideal world, we'd never fork xkbcomp, just do it all in-process with xkbcommon and cache what we can (i.e. straight rules compilations, rather than 'the current keymap plus misc'). If clients are compiling weird keymaps all the time, then I'm honestly pretty glad we're showing that up so we can go yell at people. Same way I was kind of glad for the popen vs. signals bug a while back, because it showed up the fact that OpenOffice used to ask us to rebuild the keymap every time you opened a pop-up menu. Good incentive to fix catastrophically broken clients. Cheers, Daniel _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel