I find the reason now.<br>The surface is explicitly cleared to (0, 0, 0, 1) in cairo_gl_surface_create() <br>using _cairo_gl_surface_clear(), but not cleared in <br>_cairo_gl_surface_create_similar(). However, now it's not neccessary<br>
to do clearing in _cairo_gl_surface_create_similar() because of<br>restoration of "particular fast path". It will be more effective.<br><br>
<div class="gmail_quote">2011/12/7 Chris Wilson <span dir="ltr"><<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>></span><br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div class="im">On Wed, 7 Dec 2011 20:20:33 +0800, ÍõÃ÷ <<a href="mailto:strgnm@gmail.com">strgnm@gmail.com</a>> wrote:<br>> Well, only using glBlendFuncSeperate is not enough to assure alpha value of<br>> destination surface to be 1.0. For example, if both alpha value of source<br>
> and<br>> destination surface is 0, then the result alpha is 0.<br><br></div>Except that the blend equation for a CONTENT_COLOR destination is to always<br>set the output alpha to 1.0.<br><br>> But after this commit<br>
> 6b472e12ae11f7b68289cdfd616e765be9a25a98<<a href="http://cgit.freedesktop.org/cairo/commit/?id=6b472e12ae11f7b68289cdfd616e765be9a25a98" target="_blank">http://cgit.freedesktop.org/cairo/commit/?id=6b472e12ae11f7b68289cdfd616e765be9a25a98</a>>,<br>
<br>I reiterate that cairo_surface_create_similar(CONTENT_COLOR) was already<br>being explicitly cleared to (0, 0, 0, 1) prior to the restoration of<br>that particular fast path. Whatever bug you are seeing is still present,<br>
just now papered over.<br>
<div class="HOEnZb">
<div class="h5">-Chris<br><br>--<br>Chris Wilson, Intel Open Source Technology Centre<br></div></div></blockquote></div><br>