[PATCH] wip: per-pixel surface picking

Tiago Vignatti tiago.vignatti at linux.intel.com
Fri Feb 10 01:32:21 PST 2012

On 02/10/2012 11:03 AM, Pekka Paalanen wrote:
> On Thu, 09 Feb 2012 16:41:08 -0800
> Bill Spitzak<spitzak at gmail.com>  wrote:
>> 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?
> That would be better than round-trips, sure, but there is a
> possibly heavy downside, too.
> This is a bit hand-wavy, since I don't have all the details, having
> only followed Mesa devel and not actively working on a driver.
> If we used the alpha channel of the current surface buffer, we would
> need to get the alpha value (or just a boolean from alpha<  threshold
> test) from the buffer to the CPU. The cost of getting data from GPU
> domain to CPU domain can be high, as the buffer could reside in
> non-mappable VRAM, for instance, and the kernel would need to set up a
> DMA transfer to get the data. Then you'd need to wait for the transfer
> to complete. Depending on hardware, the transfer might also require
> CPU-GPU synchronization, which is very expensive. Simply put,
> glReadPixels can kill performance.
> But, I think testing this would be worth it, because when the buffer
> comes to the compositor, all rendering to it must have already been done
> (I think), so at least we would not be waiting for the GPU to finish
> client's rendering. Then if we could somehow asychronously do the whole
> alpha channel read-out and compositing rendering at the same time,
> maybe the cost would not be prohibitive. In any case we would be eating
> a lot more system memory for every surface.


> The problem is, the cost depends on the hardware and the driver, so I
> don't think we want to enforce this as the only method in the protocol.

yeah, definitely not! I like the rule "if you draw, you can figure it 
out", meaning that each client should be free to define what's better 
for itself. So compositor could use three heuristics fed by clients:

1. touch/tap happens at [x, y]. Does it returns a client surface?
    Yes: cool, jump to step 2. No: return NULL.
2. is there a drop shadow?
    Yes: Go figure out if it's transparent and if it is, continue to
    the next surface. No: return picked surface.
3. is there a shaped window?
    Yes: Go figure out if it's transparent and if it is, continue to
    the next surface. No: return picked surface.


More information about the wayland-devel mailing list