Enabling more efficient transparent windowless painting

Robert O'Callahan robert at ocallahan.org
Thu Apr 8 21:49:07 PDT 2010

On Fri, Apr 9, 2010 at 12:21 PM, Brett Wilson <brettw at google.com> wrote:

> On Thu, Apr 8, 2010 at 4:50 PM, Robert O'Callahan <robert at ocallahan.org>
> wrote:
> > That basically sounds good to me. We only need this on X and Windows
> where
> > X/GDI can't be trusted to set alpha values correctly.
> >
> > Why do you require the browser to clear the surface? Wouldn't it be more
> > efficient for the plugin to clear it?
> In Chrome this surface is in shared memory, so it doesn't matter who
> clears it from a perf perspective. I just thought it was nice to
> define what the state of the buffer is before handing it to the
> plugin.

If the plugin knows its content is opaque, or it has the rendered content in
an internal buffer, possibly in some other format, then it doesn't need to
explicitly clear the buffer. It can just overwrite the old RGBA values with
its own values. This optimization is much harder to do if the browser is
responsible for clearing the buffer.

> We'll also want a similar "draw to GL"/"draw to D3D" API shortly. I'm not
> > sure if it's worth lumping that in here or not.
> GL sounds like it's more of a replacement of the current painting
> model, whereas my proposal is more of a mode on the current one. Does
> this sound right to you?


Conceivably, the bitmap produced by my proposal could be converted to
> a texture for accelerated painting, although the plugin itself could

not be accelerated.


"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/plugin-futures/attachments/20100409/dc86ceab/attachment.html>

More information about the plugin-futures mailing list