[webkit-dev] New web-facing canvas feature: "opaque" attribute

[Dean Jackson]

On 15/03/2013, at 6:50 AM, Dana Jansens <danakj at chromium.org> wrote:

> On Thu, Mar 14, 2013 at 3:46 PM, Dean Jackson <dino at apple.com> wrote:
> I'm not sure I like this proposal. Why is canvas special? Why doesn't <img> get an opaque attribute (or flag)? Why not every element?
> 
> There is ongoing work to infer opaqueness in every other kind of element when possible. See for example https://bugs.webkit.org/show_bug.cgi?id=70634

Yes, I'd prefer to infer it rather than specify it. For example, I could infer that a canvas is opaque if it has a non-transparent CSS background-color.

Dean

>  
> 
> I don't think the performance benefit, which is mostly going to be on very limited hardware, is worth changing the rendering model that is consistent across every other part of the Web.
> 
> Dean
> 
> On 15/03/2013, at 4:53 AM, Stephen White <senorblanco at chromium.org> wrote:
> 
>> Hi Dirk,
>> 
>> There have been at least five options considered, with contributions from Chromium, Adobe and Mozilla so far.  The moz-opaque idea was first floated by Robert O'Callahan from Mozilla, and Ian Hickson offered to spec it if another browser vendor wanted to implement it.  I took him up on that offer, and have made my humble effort to massage it into a concrete proposal in the linked message above.
>> 
>> After proposing it here, the alternative suggestion is to sync it up with the WebGL syntax, and use a context creation object at getContext() time rather than an attribute on the <canvas> element.  I have no strong feelings about this either way, and I'm working on a patch to try out the WebGL approach (I already have a WebKit patch which implements the platform-independent parts of the opaque attribute approach).  However, if we do go that way, I'd prefer not to make this proposal conditional on changes to the WebGL spec, concerns which I've outlined over on what-wg.
>> 
>> Stephen
>> 
>> 
>> On Wed, Mar 13, 2013 at 12:30 PM, Dirk Schulze <dschulze at adobe.com> wrote:
>> This is a very long thread and I did not see any conclusions or agreement on this thread. Can you summarize the topic and the status on the acceptance level please?
>> 
>> Greetings,
>> Dirk
>> 
>> On Mar 13, 2013, at 9:15 AM, Stephen White <senorblanco at chromium.org> wrote:
>> 
>> > Hi WebKittens,
>> >
>> > I'm planning to implement the canvas "opaque" attribute, as proposed here:  http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0109.html.
>> >
>> > This is an attribute that causes the allocation of an opaque backing store for <canvas>, allowing optimizations at the time the canvas is composited into the page, such as disabling blending and culling obscured content.  It is based on the moz-opaque attribute currently shipping in Firefox.
>> >
>> > I'll be placing the feature behind the build-time flag ENABLE(OPAQUE_CANVAS).
>> >
>> > Let me know if you have any comments or concerns.
>> >
>> > Stephen
>> > _______________________________________________
>> > webkit-dev mailing list
>> > webkit-dev at lists.webkit.org
>> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130315/3fa340d1/attachment.html>