[PATCH weston] compositor: automatically set opaque region for color formats

[Bill Spitzak]

Daniel Stone wrote:
> On 5 September 2012 20:49, Bill Spitzak <spitzak at gmail.com> wrote:
>> Doesn't the compositor have access to what type the surfaces are? It can
>> then know the surface is opaque and ignore the opaque region there. Then if
>> the client changes back to a non-opaque surface the opaque region is
>> unchanged and starts being used again.
>>
>> I would expect this to be slightly more efficient because the compositor
>> will also know that the opaque region is exactly equal to the surface area.
> 
> ... yeah, that's literally exactly what this patch does.

If so then I don't understand this (quoted from original message):

Note:
If a client first sends a buffer with opaque color format, and then
sends another buffer of the same size but with non-opaque color format,
the opaque region in the server is no longer what the client expects
based on protocol: it has been changed from what the client earlier
specified into whole surface. Therefore this is a protocol change.

This implies that it actually changes the opaque area, instead of the 
compositor just using the surface area *instead* of the opaque area, 
which I think makes a lot more sense.