[PATCH] wip: per-pixel surface picking

[Bill Spitzak]

You are probably right that the round-trip would be bad.

Can it just use the transparency of the current buffer, rather than 
other information that needs to be transmitted from the client?

Another possibility is that the api is simplified to *one* rectangle, 
and the client says "anything inside this rectangle is mine, anything 
outside you should check the transparency". That would allow it to skip 
the transparency check for the majority of clients but keep the api minimal.

Daniel Stone wrote:
> Hi,
> Sorry for the drive-by, but ...
> 
> On 9 February 2012 21:43, Bill Spitzak <spitzak at gmail.com> wrote:
>> I feel that a better solution is for the compositor to send any event in the
>> surface rectangle to the client, but the client is allowed to respond with a
>> "that is in the transparent area", in which case the compositor sends it to
>> a lower surface.
> 
> ... noooooooo.  Round-tripping to clients is death, and we can never do it.
> 
> Reason one -- which is almost enough in itself -- is latency, and
> fairly self-explanatory.
> 
> The second reason is that you basically have to pend all other input
> until you get a definite response one way or the other.  Say you send
> one click to the flower, another click to a terminal window, which
> raises it, and then later the flower responds to say that the click
> fell outside its non-transparent area and should be redirected to the
> client beneath it.  If you replayed it, you'd be sending events out of
> order to the terminal below it.  Disaster.
> 
> Cheers,
> Daniel