On Thu, 6 Sep 2012 11:10:39 -0400
Kristian Høgsberg wrote:
> On Wed, Sep 05, 2012 at 09:36:59AM +0300, Pekka Paalanen wrote:
> > Some color formats are naturally opaque: RGB, XRGB, YUV formats without
> > A channel. For these, automatically set the opaque region to whole
> > surface.
> >
> > Not
On Wed, Sep 05, 2012 at 09:36:59AM +0300, Pekka Paalanen wrote:
> Some color formats are naturally opaque: RGB, XRGB, YUV formats without
> A channel. For these, automatically set the opaque region to whole
> surface.
>
> Note:
> If a client first sends a buffer with opaque color format, and then
Daniel Stone wrote:
On 5 September 2012 20:49, Bill Spitzak 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
unchange
On 5 September 2012 20:49, Bill Spitzak 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 bein
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 mo
Some color formats are naturally opaque: RGB, XRGB, YUV formats without
A channel. For these, automatically set the opaque region to whole
surface.
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
