[webkit-dev] New web-facing canvas feature: opaque attribute
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@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
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 senorbla...@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@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] window.internals abuse
On Wed, Mar 13, 2013 at 9:42 AM, Simon Fraser simon.fra...@apple.comwrote: https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in http://trac.webkit.org/changeset/114081) added internals. setBackgroundBlurOnNode(). I consider this to be abuse of the Internals object. As shown by the location of the files (Source/WebCore/*testing*/Internals.*), the Internals interface is intended for testing, not adding API to toggle features in WebCore for non-test code. Sorry, I don't follow. setBackgroundBlurOnNode appears to be only called in a layout test as far as I read the patch. Where is this function called for non-testing purposes? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
It would be nice if this was the same as WebGL instead of different.
Especially because 2d canvas and WebGL need to inter-operate in the near
future.
In WebGL to create a canvas with no alpha (an opaque canvas) you do this
gl = canvas.getContext(experimental-webgl, { alpha: false });
Why can't 2D canvas be this
ctx = canvas.getContext(2d, {alpha: false});
As for why this is important to be the same see the proposal for Canvas in
Workers here (http://wiki.whatwg.org/wiki/CanvasInWorkers)
In that proposal the backingstore of a canvas can be moved to/from a
worker. That solution may or many not be the final solution but it points
out that whatever solution is chosen we need the solution to work for both
canvas 2d and WebGL and as such needs a common way to create backing stores
with no alpha.
On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze dschu...@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 senorbla...@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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] window.internals abuse
On Mar 13, 2013, at 9:48 AM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Mar 13, 2013 at 9:42 AM, Simon Fraser simon.fra...@apple.com wrote: https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in http://trac.webkit.org/changeset/114081) added internals. setBackgroundBlurOnNode(). I consider this to be abuse of the Internals object. As shown by the location of the files (Source/WebCore/testing/Internals.*), the Internals interface is intended for testing, not adding API to toggle features in WebCore for non-test code. Sorry, I don't follow. setBackgroundBlurOnNode appears to be only called in a layout test as far as I read the patch. Where is this function called for non-testing purposes? Background blur (or background filters in general) are not a web-exposed feature, so it seems odd that Internals has a switch for some non-web-exposed feature that is only implemented by one port. It feels like this was something added for a UI feature in Chromium, in which case Internals isn't an appropriate way to toggle it. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] window.internals abuse
On Wed, Mar 13, 2013 at 9:59 AM, Simon Fraser simon.fra...@apple.comwrote: On Mar 13, 2013, at 9:48 AM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Mar 13, 2013 at 9:42 AM, Simon Fraser simon.fra...@apple.comwrote: https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in http://trac.webkit.org/changeset/114081) added internals. setBackgroundBlurOnNode(). I consider this to be abuse of the Internals object. As shown by the location of the files (Source/WebCore/*testing*/Internals.*), the Internals interface is intended for testing, not adding API to toggle features in WebCore for non-test code. Sorry, I don't follow. setBackgroundBlurOnNode appears to be only called in a layout test as far as I read the patch. Where is this function called for non-testing purposes? Background blur (or background filters in general) are not a web-exposed feature, so it seems odd that Internals has a switch for some non-web-exposed feature that is only implemented by one port. It feels like this was something added for a UI feature in Chromium, in which case Internals isn't an appropriate way to toggle it. What is the rule of thumb here? Are you specifically objecting to testing features that are not Web-exposed? e.g. would you object to testing features only available in dashboard? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] window.internals abuse
On Wed, Mar 13, 2013 at 9:59 AM, Simon Fraser simon.fra...@apple.comwrote: On Mar 13, 2013, at 9:48 AM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Mar 13, 2013 at 9:42 AM, Simon Fraser simon.fra...@apple.comwrote: https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in http://trac.webkit.org/changeset/114081) added internals. setBackgroundBlurOnNode(). I consider this to be abuse of the Internals object. As shown by the location of the files (Source/WebCore/*testing*/Internals.*), the Internals interface is intended for testing, not adding API to toggle features in WebCore for non-test code. Sorry, I don't follow. setBackgroundBlurOnNode appears to be only called in a layout test as far as I read the patch. Where is this function called for non-testing purposes? Background blur (or background filters in general) are not a web-exposed feature, so it seems odd that Internals has a switch for some non-web-exposed feature that is only implemented by one port. It feels like this was something added for a UI feature in Chromium, in which case Internals isn't an appropriate way to toggle it. What is the rule of thumb here? Are you specifically objecting to testing features that are not Web-exposed? e.g. would you object to testing features only available in dashboard? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] window.internals abuse
On Wed, Mar 13, 2013 at 10:04 AM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Mar 13, 2013 at 9:59 AM, Simon Fraser simon.fra...@apple.comwrote: On Mar 13, 2013, at 9:48 AM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Mar 13, 2013 at 9:42 AM, Simon Fraser simon.fra...@apple.comwrote: https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in http://trac.webkit.org/changeset/114081) added internals. setBackgroundBlurOnNode(). I consider this to be abuse of the Internals object. As shown by the location of the files (Source/WebCore/*testing*/Internals.*), the Internals interface is intended for testing, not adding API to toggle features in WebCore for non-test code. Sorry, I don't follow. setBackgroundBlurOnNode appears to be only called in a layout test as far as I read the patch. Where is this function called for non-testing purposes? Background blur (or background filters in general) are not a web-exposed feature, so it seems odd that Internals has a switch for some non-web-exposed feature that is only implemented by one port. It feels like this was something added for a UI feature in Chromium, in which case Internals isn't an appropriate way to toggle it. What is the rule of thumb here? Are you specifically objecting to testing features that are not Web-exposed? e.g. would you object to testing features only available in dashboard? Or perhaps you're opposed to adding variables, toggles, etc... to WebCore just for the sake of testing via internals? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] window.internals abuse
On Wed, Mar 13, 2013 at 10:04 AM, Ryosuke Niwa rn...@webkit.org wrote: Background blur (or background filters in general) are not a web-exposed feature, so it seems odd that Internals has a switch for some non-web-exposed feature that is only implemented by one port. It feels like this was something added for a UI feature in Chromium, in which case Internals isn't an appropriate way to toggle it. What is the rule of thumb here? Are you specifically objecting to testing features that are not Web-exposed? e.g. would you object to testing features only available in dashboard? In my opinion, anything that is exposed trough APIs is better tested through TestRunner than Internals. The methods left on TestRunner should be the ones exposed by at least one port. Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] window.internals abuse
On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser simon.fra...@apple.comwrote: https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in http://trac.webkit.org/changeset/114081) added internals. setBackgroundBlurOnNode(). I consider this to be abuse of the Internals object. As shown by the location of the files (Source/WebCore/*testing*/Internals.*), the Internals interface is intended for testing, not adding API to toggle features in WebCore for non-test code. Sorry, but I think this is based on a misunderstanding. That function is used for enabling the feature in layout tests in order to verify it is working. It is not used in non-test code. - dana ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] window.internals abuse
On Mar 13, 2013, at 10:15 AM, Dana Jansens dan...@chromium.org wrote: On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser simon.fra...@apple.com wrote: https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in http://trac.webkit.org/changeset/114081) added internals. setBackgroundBlurOnNode(). I consider this to be abuse of the Internals object. As shown by the location of the files (Source/WebCore/testing/Internals.*), the Internals interface is intended for testing, not adding API to toggle features in WebCore for non-test code. Sorry, but I think this is based on a misunderstanding. That function is used for enabling the feature in layout tests in order to verify it is working. It is not used in non-test code. So why does the feature exist at all? Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] window.internals abuse
On Wed, Mar 13, 2013 at 1:21 PM, Simon Fraser simon.fra...@apple.comwrote: On Mar 13, 2013, at 10:15 AM, Dana Jansens dan...@chromium.org wrote: On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser simon.fra...@apple.comwrote: https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in http://trac.webkit.org/changeset/114081) added internals. setBackgroundBlurOnNode(). I consider this to be abuse of the Internals object. As shown by the location of the files (Source/WebCore/*testing*/Internals.*), the Internals interface is intended for testing, not adding API to toggle features in WebCore for non-test code. Sorry, but I think this is based on a misunderstanding. That function is used for enabling the feature in layout tests in order to verify it is working. It is not used in non-test code. So why does the feature exist at all? It can be enabled by UI code via the platform layer directly. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] LLInt without JIT
Hello, LLINT C Loop implementation is a pure JS interpretation mode, so you can't enable along with JIT. But LLINT with assembly back-end is intended to have both JIT(baseline DFG) and interpreter mode simultaneously. The main goal of LLINT assembly backend is for JIT emulation, so that code running in JIT can easily fallback(vice versa) to interpreter mode with less or no cost and also to have a triple tier virtual machine. PSB, Filip Pizlo explained about this very nicely in the current email thread :) Regards, Arun On 13 March 2013 23:35, Gabor Rapcsanyi rga...@inf.u-szeged.hu wrote: Hello! I tried to compile JSC with LLInt CLoop backend and JIT but it didn't work for me. I tried it on Mac and Linux as well. When I looked into it a little I saw some strange guards like this: Source/JavaScriptCore/llint/LLIntOpcode.h #if ENABLE(LLINT_C_LOOP) #define FOR_EACH_LLINT_NOJIT_NATIVE_HELPER(macro) \ macro(getHostCallReturnValue, 1) \ macro(ctiOpThrowNotCaught, 1) #else // !ENABLE(LLINT_C_LOOP) #define FOR_EACH_LLINT_NOJIT_NATIVE_HELPER(macro) \ // Nothing to do here. Use the JIT impl instead. #endif // !ENABLE(LLINT_C_LOOP) It seems if we have CLoop we don't have JIT. So is this configuration supported anyway or we just want to use CLoop backend if we don't have JIT support? Regards, -Gabor Awesome, thanks for the detailed response. I did not realize that going to the assembly backend would not produce a substantial improvement. But after you explanation, I can see the reasons. I'll do some more testing to see the impact. If I see it to be worthwhile and I can fix it, I'll submit a patch, otherwise a bug. On Fri, Mar 8, 2013 at 11:28 PM, Filip Pizlo fpi...@apple.com wrote: Yes. You can use the assembly LLInt backend without using the JIT. That's how I was running it when I first wrote it. I think that the code in Platform.h is being conservative, in the sense that it assumes that if ENABLE(JIT) is not set then you're compiling for a target that the LLInt wouldn't have a backend for. This makes sense, if you think about it: ENABLE_JIT is defined to 1 if we detect that we are on a hardware/OS configuration that the JIT knows how to handle, and the LLInt has backends for strictly fewer platforms than the JIT has backends for: JIT supports x86 (32 and 64), ARM (traditional and THUMB2), MIPS, and SH4; while the LLInt currently only supports x86 (32 and 64), ARM THUMB2, and MIPS. In short, requiring the JIT to use LLInt assembly backends is not a strong requirement of the LLInt; it's just an artifact of Platform.h's logic. On hardware/OS configurations where ENABLE(JIT) is set, and the LLInt is compiled to assembly, it is still possible to run with the JIT disabled. The JIT ends up being disabled at run-time in that case. We often use this for testing - you can set the JSC_useJIT environment variable to 'false' and then you're running in a LLInt-only mode. This allows for quickly checking if a bug is due to the JITs, or not. But I would also note that the purpose of the LLInt assembly backends is _not_ performance of the LLInt itself, but for performance of the triple-tier system as a whole. What those assembly backends give us is the ability to run the LLInt using the same ABI that the JSC JITs use; this in turn allows us to do two things: (1) zero-cost OSR from the LLInt to the baseline JIT, and (2) perform every JS function call assuming opportunistically that the callee has been JITed; if it isn't then the machine code entrypoint that the callee reports is just the shared LLInt entrypoint. That entrypoint, in turn, doesn't really have to do anything special - it just loads the callee from the callee stack frame, loads the bytecode pointer from the callee, and indirect-jumps into the first bytecode instruction. We wouldn't be able to do either (1) or (2) easily with a C (or C++) interpreter. I mean, we could do it, but JIT-interpreter calls would be more expensive (because of the need to set up a C interpreter stack frame). And OSR would take more effort - it wouldn't be possible for the LLInt to just jump straight into JITed code like it does now. In summary, I don't expect the LLInt cloop backend to be any slower than the LLInt assembly backends. Last I checked, it wasn't slower. I would assume that a decent C compiler will take the LLInt cloop code and do sufficient optimizations that it ends up generating roughly the same assembly code that the LLInt assembly backends generate. So, I wouldn't devote too much effort to switching from the cloop to the assembly backends unless you had evidence that (a) it would actually be faster on the benchmarks you care about; or (b) you wanted to take advantage of the LLInt's ability to rapidly tier-up to one of the JSC JITs. It is because of (b), not (a), that JSC's triple tier configuration uses the LLInt assembly backends instead of cloop.
Re: [webkit-dev] window.internals abuse
On Wed, Mar 13, 2013 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Mar 13, 2013 at 10:22 AM, Dana Jansens dan...@chromium.orgwrote: On Wed, Mar 13, 2013 at 1:21 PM, Simon Fraser simon.fra...@apple.comwrote: On Mar 13, 2013, at 10:15 AM, Dana Jansens dan...@chromium.org wrote: On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser simon.fra...@apple.comwrote: https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in http://trac.webkit.org/changeset/114081) added internals. setBackgroundBlurOnNode(). I consider this to be abuse of the Internals object. As shown by the location of the files (Source/WebCore/*testing*/Internals.*), the Internals interface is intended for testing, not adding API to toggle features in WebCore for non-test code. Sorry, but I think this is based on a misunderstanding. That function is used for enabling the feature in layout tests in order to verify it is working. It is not used in non-test code. So why does the feature exist at all? It can be enabled by UI code via the platform layer directly. That sounds like a feature to be tested via testRunner object, not internals object. internals object should be reserved for testing cross-platform, cross-port features. Otherwise, we'll end up zillion of if-defs for each and every port specific feature we want to test :( I don't think that testRunner existed in its current form a year ago when this was written. I can look into moving it there if it would be better suited. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] window.internals abuse
On Wed, Mar 13, 2013 at 11:50 AM, Dana Jansens dan...@chromium.org wrote: On Wed, Mar 13, 2013 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Mar 13, 2013 at 10:22 AM, Dana Jansens dan...@chromium.orgwrote: On Wed, Mar 13, 2013 at 1:21 PM, Simon Fraser simon.fra...@apple.comwrote: On Mar 13, 2013, at 10:15 AM, Dana Jansens dan...@chromium.org wrote: On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser simon.fra...@apple.comwrote: https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in http://trac.webkit.org/changeset/114081) added internals. setBackgroundBlurOnNode(). I consider this to be abuse of the Internals object. As shown by the location of the files (Source/WebCore/*testing*/Internals.*), the Internals interface is intended for testing, not adding API to toggle features in WebCore for non-test code. Sorry, but I think this is based on a misunderstanding. That function is used for enabling the feature in layout tests in order to verify it is working. It is not used in non-test code. So why does the feature exist at all? It can be enabled by UI code via the platform layer directly. That sounds like a feature to be tested via testRunner object, not internals object. internals object should be reserved for testing cross-platform, cross-port features. Otherwise, we'll end up zillion of if-defs for each and every port specific feature we want to test :( I don't think that testRunner existed in its current form a year ago when this was written. I can look into moving it there if it would be better suited. Of course not in the current form but testRunner (or layoutTestController before the rename) object have existed for years. It had been the de facto standard way of exposing new testing functions to layout tests until we've introduced internals object two years ago. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
An attribute on the canvas element would presumably be equally applicable to
all contexts. Is there a reason that it's better to have opaqueness specified
at context creation time instead of on the canvas? Also, I think opaque is
easier to understand than alpha: false.
- Maciej
On Mar 13, 2013, at 9:57 AM, Gregg Tavares g...@google.com wrote:
It would be nice if this was the same as WebGL instead of different.
Especially because 2d canvas and WebGL need to inter-operate in the near
future.
In WebGL to create a canvas with no alpha (an opaque canvas) you do this
gl = canvas.getContext(experimental-webgl, { alpha: false });
Why can't 2D canvas be this
ctx = canvas.getContext(2d, {alpha: false});
As for why this is important to be the same see the proposal for Canvas in
Workers here (http://wiki.whatwg.org/wiki/CanvasInWorkers)
In that proposal the backingstore of a canvas can be moved to/from a
worker. That solution may or many not be the final solution but it points out
that whatever solution is chosen we need the solution to work for both canvas
2d and WebGL and as such needs a common way to create backing stores with no
alpha.
On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze dschu...@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 senorbla...@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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
I think opaque vs. alpha: false is a matter of opinion. The
functionality doesn't change, regardless of what you call it.
I agree with Gregg that this really should be implemented to reflect the
functionality that WebGL already has. Wether 2D or 3D, there's a lot of
common ground between the various canvas contexts and it doesn't make much
sense to reinvent the wheel when one context type has already implemented
the functionality.
--Brandon
On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote:
An attribute on the canvas element would presumably be equally applicable
to all contexts. Is there a reason that it's better to have opaqueness
specified at context creation time instead of on the canvas? Also, I think
opaque is easier to understand than alpha: false.
- Maciej
On Mar 13, 2013, at 9:57 AM, Gregg Tavares g...@google.com wrote:
It would be nice if this was the same as WebGL instead of different.
Especially because 2d canvas and WebGL need to inter-operate in the near
future.
In WebGL to create a canvas with no alpha (an opaque canvas) you do this
gl = canvas.getContext(experimental-webgl, { alpha: false });
Why can't 2D canvas be this
ctx = canvas.getContext(2d, {alpha: false});
As for why this is important to be the same see the proposal for Canvas in
Workers here (http://wiki.whatwg.org/wiki/CanvasInWorkers)
In that proposal the backingstore of a canvas can be moved to/from a
worker. That solution may or many not be the final solution but it points
out that whatever solution is chosen we need the solution to work for both
canvas 2d and WebGL and as such needs a common way to create backing stores
with no alpha.
On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze dschu...@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 senorbla...@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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
The main reason for this feature is to enhance performance of canvas
operations.
Are we certain that this will always be the case? For instance, is google
going to make certain that the cairo and core graphics backends don't slow
down?
Rik
On Wed, Mar 13, 2013 at 1:21 PM, Brandon Jones bajo...@google.com wrote:
I think opaque vs. alpha: false is a matter of opinion. The
functionality doesn't change, regardless of what you call it.
I agree with Gregg that this really should be implemented to reflect the
functionality that WebGL already has. Wether 2D or 3D, there's a lot of
common ground between the various canvas contexts and it doesn't make much
sense to reinvent the wheel when one context type has already implemented
the functionality.
--Brandon
On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote:
An attribute on the canvas element would presumably be equally applicable
to all contexts. Is there a reason that it's better to have opaqueness
specified at context creation time instead of on the canvas? Also, I think
opaque is easier to understand than alpha: false.
- Maciej
On Mar 13, 2013, at 9:57 AM, Gregg Tavares g...@google.com wrote:
It would be nice if this was the same as WebGL instead of different.
Especially because 2d canvas and WebGL need to inter-operate in the near
future.
In WebGL to create a canvas with no alpha (an opaque canvas) you do this
gl = canvas.getContext(experimental-webgl, { alpha: false });
Why can't 2D canvas be this
ctx = canvas.getContext(2d, {alpha: false});
As for why this is important to be the same see the proposal for Canvas
in Workers here (http://wiki.whatwg.org/wiki/CanvasInWorkers)
In that proposal the backingstore of a canvas can be moved to/from a
worker. That solution may or many not be the final solution but it points
out that whatever solution is chosen we need the solution to work for both
canvas 2d and WebGL and as such needs a common way to create backing stores
with no alpha.
On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze dschu...@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 senorbla...@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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best practices for landing new/changed layout test expectations?
The steps described here differ from what I've been doing. In the interest of closure and port happiness, I've updated the wiki to reflect what is being proposed: https://trac.webkit.org/wiki/CreatingLayoutTests Please feel free to update it further. Philip On Tue, Feb 26, 2013 at 2:34 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 26, 2013 at 1:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 26, 2013 at 12:47 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 26, 2013 at 2:11 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 26, 2013 at 1:55 AM, Tom Hudson tomhud...@google.com wrote: On Mon, Feb 25, 2013 at 10:34 PM, Ryosuke Niwa rn...@webkit.org wrote: It should be fairly straight forward to create a tool that analyzes files changed in each commit and deduce which tests' expected results have been changed. The tool can then fetch results from each port' bot for those tests and automatically land them. It can then comment on the bug automatically about these rebaseline commits. There is no need to add remove entries from TestExpectation files. Wait, what? For some reason neither I nor the mailing list archives got your initial message, nor Silvia or Tom's responses, nor your responses (at least as of the time of me writing this), so I feel like I've missed a radical shift in this thread, and maybe I missed some of the context. https://lists.webkit.org/pipermail/webkit-dev/2013-February/023967.html This link doesn't point to any of those messages, but perhaps it's not that important. You're proposing that we automatically land updated baselines without review and then somehow update bugs, have people go back and look at the updated bugs to see if the baseline changes represent actual regressions or just expected changes? Right. Given that the commit already contains information as to which tests have been rebaselined, a script should be able to fetch new baselines for those affected tests on each platform and land them or upload as patches as needed. It's possible that we could fetch and cluster new baselines based on what changed in the initial commit. I would be concerned that there could be a fair amount of noise in either direction (tests that changed on the initial platform didn't on others, and others did), and you'd also have to figure out how to cluster changes since most builds on the bots contain multiple changes. But, you could probably use some of garden-o-matic's results to help here. That said, I'm not sure this workflow would actually improve things much over garden-o-matic. I am quite a bit more reluctant to automatically land any such changes; it seems like it would be hard if not impossible to tell (programmatically) whether a baseline changed as expected or if it represented a regression. If we were to work on new tooling, I would be much more in favor of pushing this up to an EWS-time step like Ossy suggests. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
alpha:false is super confusing to me. It makes it sound as though all
draw*() operations that use an alpha channel will fail... does globalAlpha
still work?
It's sad that WebGL picked such a generic name that isn't about all alpha
related things.
On Wed, Mar 13, 2013 at 2:59 PM, Rik Cabanier caban...@gmail.com wrote:
The main reason for this feature is to enhance performance of canvas
operations.
Are we certain that this will always be the case? For instance, is google
going to make certain that the cairo and core graphics backends don't slow
down?
Rik
On Wed, Mar 13, 2013 at 1:21 PM, Brandon Jones bajo...@google.com wrote:
I think opaque vs. alpha: false is a matter of opinion. The
functionality doesn't change, regardless of what you call it.
I agree with Gregg that this really should be implemented to reflect the
functionality that WebGL already has. Wether 2D or 3D, there's a lot of
common ground between the various canvas contexts and it doesn't make much
sense to reinvent the wheel when one context type has already implemented
the functionality.
--Brandon
On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote:
An attribute on the canvas element would presumably be equally
applicable to all contexts. Is there a reason that it's better to have
opaqueness specified at context creation time instead of on the canvas?
Also, I think opaque is easier to understand than alpha: false.
- Maciej
On Mar 13, 2013, at 9:57 AM, Gregg Tavares g...@google.com wrote:
It would be nice if this was the same as WebGL instead of different.
Especially because 2d canvas and WebGL need to inter-operate in the near
future.
In WebGL to create a canvas with no alpha (an opaque canvas) you do this
gl = canvas.getContext(experimental-webgl, { alpha: false });
Why can't 2D canvas be this
ctx = canvas.getContext(2d, {alpha: false});
As for why this is important to be the same see the proposal for Canvas
in Workers here (http://wiki.whatwg.org/wiki/CanvasInWorkers)
In that proposal the backingstore of a canvas can be moved to/from a
worker. That solution may or many not be the final solution but it points
out that whatever solution is chosen we need the solution to work for both
canvas 2d and WebGL and as such needs a common way to create backing stores
with no alpha.
On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze dschu...@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 senorbla...@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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best practices for landing new/changed layout test expectations?
Thanks for following up Philip. I don't feel like this thread met much consensus, more just went off into the weeds. Given the history of that page, I'm not sure it truly reflects the consensus of the project: https://trac.webkit.org/wiki/CreatingLayoutTests?action=history Regardless of whether you are making a platform independent change or dependent change, it is your responsibility to ensure that the change does not negatively affect any other ports / platforms. This includes updating platform specific results or contacting a port maintainer to do this for you (for contacts, see: http://trac.webkit.org/wiki/WebKit%20Team). I'm not sure I see anyone following this these days. The EWS system and sherriffiing cultures seem to have largely replaced bot-monitoring. We also don't really have a system of core ports, thus all ports seems a bit broad here. Once your change is landed, there are some steps required to verify the change. Note: These steps apply for all changes. If you are making a platform dependent change, you should expect that additional results will be required for each platform but the actions are the same. I'm not sure it makes any sense to ask contributors to update other ports. In many cases, it's not possible for contributors to even build other ports. We clearly need some sort of automated system for this, but right now I believe the expectation is that maintainers of the various ports will add the port-specific results, and that those contributing new layout tests should just land their results as the common ones? But I could be mistaken. I think the reality is that the project doesn't really have consensus here, likely meaning this is a good topic for the contributors meeting. On Wed, Mar 13, 2013 at 3:12 PM, Philip Rogers p...@google.com wrote: The steps described here differ from what I've been doing. In the interest of closure and port happiness, I've updated the wiki to reflect what is being proposed: https://trac.webkit.org/wiki/CreatingLayoutTests Please feel free to update it further. Philip On Tue, Feb 26, 2013 at 2:34 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 26, 2013 at 1:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 26, 2013 at 12:47 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 26, 2013 at 2:11 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 26, 2013 at 1:55 AM, Tom Hudson tomhud...@google.com wrote: On Mon, Feb 25, 2013 at 10:34 PM, Ryosuke Niwa rn...@webkit.org wrote: It should be fairly straight forward to create a tool that analyzes files changed in each commit and deduce which tests' expected results have been changed. The tool can then fetch results from each port' bot for those tests and automatically land them. It can then comment on the bug automatically about these rebaseline commits. There is no need to add remove entries from TestExpectation files. Wait, what? For some reason neither I nor the mailing list archives got your initial message, nor Silvia or Tom's responses, nor your responses (at least as of the time of me writing this), so I feel like I've missed a radical shift in this thread, and maybe I missed some of the context. https://lists.webkit.org/pipermail/webkit-dev/2013-February/023967.html This link doesn't point to any of those messages, but perhaps it's not that important. You're proposing that we automatically land updated baselines without review and then somehow update bugs, have people go back and look at the updated bugs to see if the baseline changes represent actual regressions or just expected changes? Right. Given that the commit already contains information as to which tests have been rebaselined, a script should be able to fetch new baselines for those affected tests on each platform and land them or upload as patches as needed. It's possible that we could fetch and cluster new baselines based on what changed in the initial commit. I would be concerned that there could be a fair amount of noise in either direction (tests that changed on the initial platform didn't on others, and others did), and you'd also have to figure out how to cluster changes since most builds on the bots contain multiple changes. But, you could probably use some of garden-o-matic's results to help here. That said, I'm not sure this workflow would actually improve things much over garden-o-matic. I am quite a bit more reluctant to automatically land any such changes; it seems like it would be hard if not impossible to tell (programmatically) whether a baseline changed as expected or if it represented a regression. If we were to work on new tooling, I would be much more in favor of pushing this up to an EWS-time step like Ossy suggests. -- Dirk ___ webkit-dev mailing list
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
globalAlpha will still work but will always composite with an opaque
backdrop (which is black by default)
On Wed, Mar 13, 2013 at 3:25 PM, Elliott Sprehn espr...@chromium.orgwrote:
alpha:false is super confusing to me. It makes it sound as though all
draw*() operations that use an alpha channel will fail... does globalAlpha
still work?
It's sad that WebGL picked such a generic name that isn't about all
alpha related things.
On Wed, Mar 13, 2013 at 2:59 PM, Rik Cabanier caban...@gmail.com wrote:
The main reason for this feature is to enhance performance of canvas
operations.
Are we certain that this will always be the case? For instance, is google
going to make certain that the cairo and core graphics backends don't slow
down?
Rik
On Wed, Mar 13, 2013 at 1:21 PM, Brandon Jones bajo...@google.comwrote:
I think opaque vs. alpha: false is a matter of opinion. The
functionality doesn't change, regardless of what you call it.
I agree with Gregg that this really should be implemented to reflect the
functionality that WebGL already has. Wether 2D or 3D, there's a lot of
common ground between the various canvas contexts and it doesn't make much
sense to reinvent the wheel when one context type has already implemented
the functionality.
--Brandon
On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak m...@apple.comwrote:
An attribute on the canvas element would presumably be equally
applicable to all contexts. Is there a reason that it's better to have
opaqueness specified at context creation time instead of on the canvas?
Also, I think opaque is easier to understand than alpha: false.
- Maciej
On Mar 13, 2013, at 9:57 AM, Gregg Tavares g...@google.com wrote:
It would be nice if this was the same as WebGL instead of different.
Especially because 2d canvas and WebGL need to inter-operate in the near
future.
In WebGL to create a canvas with no alpha (an opaque canvas) you do this
gl = canvas.getContext(experimental-webgl, { alpha: false });
Why can't 2D canvas be this
ctx = canvas.getContext(2d, {alpha: false});
As for why this is important to be the same see the proposal for Canvas
in Workers here (http://wiki.whatwg.org/wiki/CanvasInWorkers)
In that proposal the backingstore of a canvas can be moved to/from a
worker. That solution may or many not be the final solution but it points
out that whatever solution is chosen we need the solution to work for both
canvas 2d and WebGL and as such needs a common way to create backing stores
with no alpha.
On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze dschu...@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 senorbla...@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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote:
An attribute on the canvas element would presumably be equally applicable
to all contexts. Is there a reason that it's better to have opaqueness
specified at context creation time instead of on the canvas?
Changing opaque requires recreating the backingstore for a canvas and
destroying all state on the 2D context object, same as changing width or
height. It's preferable to do such heavy operations once. Especially since
it doesn't seem likely apps will change this often.
Also, I think opaque is easier to understand than alpha: false.
- Maciej
On Mar 13, 2013, at 9:57 AM, Gregg Tavares g...@google.com wrote:
It would be nice if this was the same as WebGL instead of different.
Especially because 2d canvas and WebGL need to inter-operate in the near
future.
In WebGL to create a canvas with no alpha (an opaque canvas) you do this
gl = canvas.getContext(experimental-webgl, { alpha: false });
Why can't 2D canvas be this
ctx = canvas.getContext(2d, {alpha: false});
As for why this is important to be the same see the proposal for Canvas in
Workers here (http://wiki.whatwg.org/wiki/CanvasInWorkers)
In that proposal the backingstore of a canvas can be moved to/from a
worker. That solution may or many not be the final solution but it points
out that whatever solution is chosen we need the solution to work for both
canvas 2d and WebGL and as such needs a common way to create backing stores
with no alpha.
On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze dschu...@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 senorbla...@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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
WebGL chose alpha because it's a context creation attribute, to go along with
other attributes like depth stencil etc. It makes more sense for WebGL
because there are a set of these. For Canvas 2D, the only two that I think
could apply are alpha and preseveDrawingBuffer. The canvas itself behaves
normally.
moz-opaque was a hack when we saw that we could get a good speed win on mobile
(since you can just blit instead of doing a blend); it came into being before
the context creation attributes were added to the canvas spec.
I'd suggest adding context creation params to the canvas-2d context, to unify
usage with WebGL and to make it easy to extend (e.g., preserveDrawingBuffer
mentioned above). Firefox may well even stop supporting moz-opaque; we never
really publicized it anywhere and just used it internally in the Firefox UI.
- Vlad
- Original Message -
From: Elliott Sprehn espr...@chromium.org
To: Rik Cabanier caban...@gmail.com
Cc: WebKit Development webkit-dev@lists.webkit.org
Sent: Wednesday, March 13, 2013 6:25:53 PM
Subject: Re: [webkit-dev] New web-facing canvas feature: opaque attribute
alpha:false is super confusing to me. It makes it sound as though all
draw*() operations that use an alpha channel will fail... does
globalAlpha still work?
It's sad that WebGL picked such a generic name that isn't about all
alpha related things.
On Wed, Mar 13, 2013 at 2:59 PM, Rik Cabanier caban...@gmail.com
wrote:
The main reason for this feature is to enhance performance of canvas
operations.
Are we certain that this will always be the case? For instance, is
google going to make certain that the cairo and core graphics
backends don't slow down?
Rik
On Wed, Mar 13, 2013 at 1:21 PM, Brandon Jones bajo...@google.com
wrote:
I think opaque vs. alpha: false is a matter of opinion. The
functionality doesn't change, regardless of what you call it.
I agree with Gregg that this really should be implemented to reflect
the functionality that WebGL already has. Wether 2D or 3D, there's a
lot of common ground between the various canvas contexts and it
doesn't make much sense to reinvent the wheel when one context type
has already implemented the functionality.
--Brandon
On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak m...@apple.com
wrote:
An attribute on the canvas element would presumably be equally
applicable to all contexts. Is there a reason that it's better to
have opaqueness specified at context creation time instead of on the
canvas? Also, I think opaque is easier to understand than alpha:
false.
- Maciej
On Mar 13, 2013, at 9:57 AM, Gregg Tavares g...@google.com wrote:
It would be nice if this was the same as WebGL instead of different.
Especially because 2d canvas and WebGL need to inter-operate in the
near future.
In WebGL to create a canvas with no alpha (an opaque canvas) you do
this
gl = canvas.getContext(experimental-webgl, { alpha: false });
Why can't 2D canvas be this
ctx = canvas.getContext(2d, {alpha: false});
As for why this is important to be the same see the proposal for
Canvas in Workers here ( http://wiki.whatwg.org/wiki/CanvasInWorkers
)
In that proposal the backingstore of a canvas can be moved to/from
a worker. That solution may or many not be the final solution but it
points out that whatever solution is chosen we need the solution to
work for both canvas 2d and WebGL and as such needs a common way to
create backing stores with no alpha.
On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze dschu...@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 senorbla...@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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
Two questions/comments:
1) What happens if I do:
gl = canvas.getContext(experimental-webgl, { alpha: false });
and then later, in an unrelated piece of code I do the following on the same
canvas:
gl = canvas.getContext(experimental-webgl);
Will the canvas remain opaque? Will the buffer be wiped? Will it turn
non-opaque without wiping the buffer? Based on my guesses of the answers to
these questions, I feel like this approach is dangerous because you have to
remember to pass the right parameters each time you retrieve the context. But
really you should be able to set it once and then retrieve the context an
arbitrary number of times without repeating yourself.
2) I think alpha: false is a particularly bad name for the reasons Elliott
stated - it sounds like it would disable all alpha compositing for all drawing
operations done within the canvas, whereas what it actually does is force the
composited results of canvas drawing to have alpha of 1.0. Is WebGL locked into
the alpha: false syntax?
Regards,
Maciej
On Mar 13, 2013, at 7:57 PM, Vladimir Vukicevic vladi...@mozilla.com wrote:
WebGL chose alpha because it's a context creation attribute, to go along with
other attributes like depth stencil etc. It makes more sense for WebGL
because there are a set of these. For Canvas 2D, the only two that I think
could apply are alpha and preseveDrawingBuffer. The canvas itself
behaves normally.
moz-opaque was a hack when we saw that we could get a good speed win on
mobile (since you can just blit instead of doing a blend); it came into being
before the context creation attributes were added to the canvas spec.
I'd suggest adding context creation params to the canvas-2d context, to unify
usage with WebGL and to make it easy to extend (e.g., preserveDrawingBuffer
mentioned above). Firefox may well even stop supporting moz-opaque; we never
really publicized it anywhere and just used it internally in the Firefox UI.
- Vlad
- Original Message -
From: Elliott Sprehn espr...@chromium.org
To: Rik Cabanier caban...@gmail.com
Cc: WebKit Development webkit-dev@lists.webkit.org
Sent: Wednesday, March 13, 2013 6:25:53 PM
Subject: Re: [webkit-dev] New web-facing canvas feature: opaque attribute
alpha:false is super confusing to me. It makes it sound as though all
draw*() operations that use an alpha channel will fail... does
globalAlpha still work?
It's sad that WebGL picked such a generic name that isn't about all
alpha related things.
On Wed, Mar 13, 2013 at 2:59 PM, Rik Cabanier caban...@gmail.com
wrote:
The main reason for this feature is to enhance performance of canvas
operations.
Are we certain that this will always be the case? For instance, is
google going to make certain that the cairo and core graphics
backends don't slow down?
Rik
On Wed, Mar 13, 2013 at 1:21 PM, Brandon Jones bajo...@google.com
wrote:
I think opaque vs. alpha: false is a matter of opinion. The
functionality doesn't change, regardless of what you call it.
I agree with Gregg that this really should be implemented to reflect
the functionality that WebGL already has. Wether 2D or 3D, there's a
lot of common ground between the various canvas contexts and it
doesn't make much sense to reinvent the wheel when one context type
has already implemented the functionality.
--Brandon
On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak m...@apple.com
wrote:
An attribute on the canvas element would presumably be equally
applicable to all contexts. Is there a reason that it's better to
have opaqueness specified at context creation time instead of on the
canvas? Also, I think opaque is easier to understand than alpha:
false.
- Maciej
On Mar 13, 2013, at 9:57 AM, Gregg Tavares g...@google.com wrote:
It would be nice if this was the same as WebGL instead of different.
Especially because 2d canvas and WebGL need to inter-operate in the
near future.
In WebGL to create a canvas with no alpha (an opaque canvas) you do
this
gl = canvas.getContext(experimental-webgl, { alpha: false });
Why can't 2D canvas be this
ctx = canvas.getContext(2d, {alpha: false});
As for why this is important to be the same see the proposal for
Canvas in Workers here ( http://wiki.whatwg.org/wiki/CanvasInWorkers
)
In that proposal the backingstore of a canvas can be moved to/from
a worker. That solution may or many not be the final solution but it
points out that whatever solution is chosen we need the solution to
work for both canvas 2d and WebGL and as such needs a common way to
create backing stores with no alpha.
On Wed, Mar 13, 2013 at 9:30 AM, Dirk Schulze dschu...@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
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
On Wed, Mar 13, 2013 at 9:20 PM, Maciej Stachowiak m...@apple.com wrote:
Two questions/comments:
1) What happens if I do:
gl = canvas.getContext(experimental-webgl, { alpha: false });
and then later, in an unrelated piece of code I do the following on the
same canvas:
gl = canvas.getContext(experimental-webgl);
Will the canvas remain opaque? Will the buffer be wiped? Will it turn
non-opaque without wiping the buffer? Based on my guesses of the answers to
these questions, I feel like this approach is dangerous because you have to
remember to pass the right parameters each time you retrieve the context.
But really you should be able to set it once and then retrieve the context
an arbitrary number of times without repeating yourself.
The parameters are ignored the second time. The spec already says you get
the same context that was create the first time you called getContext.
2) I think alpha: false is a particularly bad name for the reasons Elliott
stated - it sounds like it would disable all alpha compositing for all
drawing operations done within the canvas, whereas what it actually does is
force the composited results of canvas drawing to have alpha of 1.0. Is
WebGL locked into the alpha: false syntax?
alpha: false means there is no alpha channel, effectively making it 1.0.
You can't write to it. If you try to read it (readPixels, getImageData) all
the alpha data will be 255. It says nothing about compositing. But, the
fact that the UA knows this guarantees there is either no alpha or that
alpha is 1.0 through the entire surface means that UA and choose to render
without blending when appropriate.
Regards,
Maciej
On Mar 13, 2013, at 7:57 PM, Vladimir Vukicevic vladi...@mozilla.com
wrote:
WebGL chose alpha because it's a context creation attribute, to go along
with other attributes like depth stencil etc. It makes more sense for
WebGL because there are a set of these. For Canvas 2D, the only two that I
think could apply are alpha and preseveDrawingBuffer. The canvas
itself behaves normally.
moz-opaque was a hack when we saw that we could get a good speed win on
mobile (since you can just blit instead of doing a blend); it came into
being before the context creation attributes were added to the canvas
spec.
I'd suggest adding context creation params to the canvas-2d context, to
unify usage with WebGL and to make it easy to extend (e.g.,
preserveDrawingBuffer mentioned above). Firefox may well even stop
supporting moz-opaque; we never really publicized it anywhere and just used
it internally in the Firefox UI.
- Vlad
- Original Message -
From: Elliott Sprehn espr...@chromium.org
To: Rik Cabanier caban...@gmail.com
Cc: WebKit Development webkit-dev@lists.webkit.org
Sent: Wednesday, March 13, 2013 6:25:53 PM
Subject: Re: [webkit-dev] New web-facing canvas feature: opaque attribute
alpha:false is super confusing to me. It makes it sound as though all
draw*() operations that use an alpha channel will fail... does
globalAlpha still work?
It's sad that WebGL picked such a generic name that isn't about all
alpha related things.
On Wed, Mar 13, 2013 at 2:59 PM, Rik Cabanier caban...@gmail.com
wrote:
The main reason for this feature is to enhance performance of canvas
operations.
Are we certain that this will always be the case? For instance, is
google going to make certain that the cairo and core graphics
backends don't slow down?
Rik
On Wed, Mar 13, 2013 at 1:21 PM, Brandon Jones bajo...@google.com
wrote:
I think opaque vs. alpha: false is a matter of opinion. The
functionality doesn't change, regardless of what you call it.
I agree with Gregg that this really should be implemented to reflect
the functionality that WebGL already has. Wether 2D or 3D, there's a
lot of common ground between the various canvas contexts and it
doesn't make much sense to reinvent the wheel when one context type
has already implemented the functionality.
--Brandon
On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak m...@apple.com
wrote:
An attribute on the canvas element would presumably be equally
applicable to all contexts. Is there a reason that it's better to
have opaqueness specified at context creation time instead of on the
canvas? Also, I think opaque is easier to understand than alpha:
false.
- Maciej
On Mar 13, 2013, at 9:57 AM, Gregg Tavares g...@google.com wrote:
It would be nice if this was the same as WebGL instead of different.
Especially because 2d canvas and WebGL need to inter-operate in the
near future.
In WebGL to create a canvas with no alpha (an opaque canvas) you do
this
gl = canvas.getContext(experimental-webgl, { alpha: false });
Why can't 2D canvas be this
ctx = canvas.getContext(2d, {alpha: false});
As for why this is important to be the same see the proposal for
Canvas in Workers here (
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
On Wed, Mar 13, 2013 at 9:49 PM, Gregg Tavares g...@google.com wrote:
On Wed, Mar 13, 2013 at 9:20 PM, Maciej Stachowiak m...@apple.com wrote:
Two questions/comments:
1) What happens if I do:
gl = canvas.getContext(experimental-webgl, { alpha: false });
and then later, in an unrelated piece of code I do the following on the
same canvas:
gl = canvas.getContext(experimental-webgl);
Will the canvas remain opaque? Will the buffer be wiped? Will it turn
non-opaque without wiping the buffer? Based on my guesses of the answers to
these questions, I feel like this approach is dangerous because you have to
remember to pass the right parameters each time you retrieve the context.
But really you should be able to set it once and then retrieve the context
an arbitrary number of times without repeating yourself.
The parameters are ignored the second time. The spec already says you get
the same context that was create the first time you called getContext.
2) I think alpha: false is a particularly bad name for the reasons
Elliott stated - it sounds like it would disable all alpha compositing for
all drawing operations done within the canvas, whereas what it actually
does is force the composited results of canvas drawing to have alpha of
1.0. Is WebGL locked into the alpha: false syntax?
alpha: false means there is no alpha channel, effectively making it 1.0.
You can't write to it. If you try to read it (readPixels, getImageData) all
the alpha data will be 255. It says nothing about compositing. But, the
fact that the UA knows this guarantees there is either no alpha or that
alpha is 1.0 through the entire surface means that UA and choose to render
without blending when appropriate.
s/and choose/can choose/
Regards,
Maciej
On Mar 13, 2013, at 7:57 PM, Vladimir Vukicevic vladi...@mozilla.com
wrote:
WebGL chose alpha because it's a context creation attribute, to go along
with other attributes like depth stencil etc. It makes more sense for
WebGL because there are a set of these. For Canvas 2D, the only two that I
think could apply are alpha and preseveDrawingBuffer. The canvas
itself behaves normally.
moz-opaque was a hack when we saw that we could get a good speed win on
mobile (since you can just blit instead of doing a blend); it came into
being before the context creation attributes were added to the canvas
spec.
I'd suggest adding context creation params to the canvas-2d context, to
unify usage with WebGL and to make it easy to extend (e.g.,
preserveDrawingBuffer mentioned above). Firefox may well even stop
supporting moz-opaque; we never really publicized it anywhere and just used
it internally in the Firefox UI.
- Vlad
- Original Message -
From: Elliott Sprehn espr...@chromium.org
To: Rik Cabanier caban...@gmail.com
Cc: WebKit Development webkit-dev@lists.webkit.org
Sent: Wednesday, March 13, 2013 6:25:53 PM
Subject: Re: [webkit-dev] New web-facing canvas feature: opaque
attribute
alpha:false is super confusing to me. It makes it sound as though all
draw*() operations that use an alpha channel will fail... does
globalAlpha still work?
It's sad that WebGL picked such a generic name that isn't about all
alpha related things.
On Wed, Mar 13, 2013 at 2:59 PM, Rik Cabanier caban...@gmail.com
wrote:
The main reason for this feature is to enhance performance of canvas
operations.
Are we certain that this will always be the case? For instance, is
google going to make certain that the cairo and core graphics
backends don't slow down?
Rik
On Wed, Mar 13, 2013 at 1:21 PM, Brandon Jones bajo...@google.com
wrote:
I think opaque vs. alpha: false is a matter of opinion. The
functionality doesn't change, regardless of what you call it.
I agree with Gregg that this really should be implemented to reflect
the functionality that WebGL already has. Wether 2D or 3D, there's a
lot of common ground between the various canvas contexts and it
doesn't make much sense to reinvent the wheel when one context type
has already implemented the functionality.
--Brandon
On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak m...@apple.com
wrote:
An attribute on the canvas element would presumably be equally
applicable to all contexts. Is there a reason that it's better to
have opaqueness specified at context creation time instead of on the
canvas? Also, I think opaque is easier to understand than alpha:
false.
- Maciej
On Mar 13, 2013, at 9:57 AM, Gregg Tavares g...@google.com wrote:
It would be nice if this was the same as WebGL instead of different.
Especially because 2d canvas and WebGL need to inter-operate in the
near future.
In WebGL to create a canvas with no alpha (an opaque canvas) you do
this
gl = canvas.getContext(experimental-webgl, { alpha: false });
Why can't 2D canvas be this
ctx = canvas.getContext(2d, {alpha: false});
As for why
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
On Mar 13, 2013, at 9:49 PM, Gregg Tavares g...@google.com wrote:
On Wed, Mar 13, 2013 at 9:20 PM, Maciej Stachowiak m...@apple.com wrote:
Two questions/comments:
1) What happens if I do:
gl = canvas.getContext(experimental-webgl, { alpha: false });
and then later, in an unrelated piece of code I do the following on the same
canvas:
gl = canvas.getContext(experimental-webgl);
Will the canvas remain opaque? Will the buffer be wiped? Will it turn
non-opaque without wiping the buffer? Based on my guesses of the answers to
these questions, I feel like this approach is dangerous because you have to
remember to pass the right parameters each time you retrieve the context. But
really you should be able to set it once and then retrieve the context an
arbitrary number of times without repeating yourself.
The parameters are ignored the second time. The spec already says you get the
same context that was create the first time you called getContext.
You're right, the spec does seem to say that. So there's no way to change this
parameter once set for a given canvas, even if it's passed explicitly? That is
strange API design but I guess it doesn't have the hazard I suggested.
2) I think alpha: false is a particularly bad name for the reasons Elliott
stated - it sounds like it would disable all alpha compositing for all
drawing operations done within the canvas, whereas what it actually does is
force the composited results of canvas drawing to have alpha of 1.0. Is WebGL
locked into the alpha: false syntax?
alpha: false means there is no alpha channel, effectively making it 1.0.
You can't write to it. If you try to read it (readPixels, getImageData) all
the alpha data will be 255. It says nothing about compositing. But, the fact
that the UA knows this guarantees there is either no alpha or that alpha is
1.0 through the entire surface means that UA and choose to render without
blending when appropriate.
I understand what it does, I'm just saying that it's a confusing way to
describe the concept.
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
On Wed, Mar 13, 2013 at 9:49 PM, Gregg Tavares g...@google.com wrote:
On Wed, Mar 13, 2013 at 9:20 PM, Maciej Stachowiak m...@apple.com wrote:
Two questions/comments:
1) What happens if I do:
gl = canvas.getContext(experimental-webgl, { alpha: false });
and then later, in an unrelated piece of code I do the following on the
same canvas:
gl = canvas.getContext(experimental-webgl);
Will the canvas remain opaque? Will the buffer be wiped? Will it turn
non-opaque without wiping the buffer? Based on my guesses of the answers to
these questions, I feel like this approach is dangerous because you have to
remember to pass the right parameters each time you retrieve the context.
But really you should be able to set it once and then retrieve the context
an arbitrary number of times without repeating yourself.
The parameters are ignored the second time. The spec already says you get
the same context that was create the first time you called getContext.
That sounds horribly confusing. Can we please change this API?
2) I think alpha: false is a particularly bad name for the reasons Elliott
stated - it sounds like it would disable all alpha compositing for all
drawing operations done within the canvas, whereas what it actually does is
force the composited results of canvas drawing to have alpha of 1.0. Is
WebGL locked into the alpha: false syntax?
alpha: false means there is no alpha channel, effectively making it 1.0.
You can't write to it. If you try to read it (readPixels, getImageData) all
the alpha data will be 255. It says nothing about compositing. But, the
fact that the UA knows this guarantees there is either no alpha or that
alpha is 1.0 through the entire surface means that UA and choose to render
without blending when appropriate.
I agree with others that this is a very misleading name. I get the
sentiment of it but it's a bad name nonetheless.
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
