On Wed, Mar 13, 2013 at 9:49 PM, Gregg Tavares wrote:
> On Wed, Mar 13, 2013 at 9:20 PM, Maciej Stachowiak 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
On Mar 13, 2013, at 9:49 PM, Gregg Tavares wrote:
>
>
>
> On Wed, Mar 13, 2013 at 9:20 PM, Maciej Stachowiak 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
On Wed, Mar 13, 2013 at 9:49 PM, Gregg Tavares wrote:
>
>
>
> On Wed, Mar 13, 2013 at 9:20 PM, Maciej Stachowiak wrote:
>
>>
>> Two questions/comments:
>>
>> 1) What happens if I do:
>> gl = canvas.getContext("experimental-webgl", { alpha: false });
>> and then later, in an unrelated piece o
On Wed, Mar 13, 2013 at 9:20 PM, Maciej Stachowiak 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.getCo
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 buf
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 it
On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak 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 requir
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 wrote:
> alpha:false is super confusing to me. It makes it sound as though all
> draw*() operations that use an alpha channel will fail... doe
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 wheth
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
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
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 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 v
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
On Wed, Mar 13, 2013 at 11:50 AM, Dana Jansens wrote:
> On Wed, Mar 13, 2013 at 1:25 PM, Ryosuke Niwa wrote:
>
>> On Wed, Mar 13, 2013 at 10:22 AM, Dana Jansens wrote:
>>
>>> On Wed, Mar 13, 2013 at 1:21 PM, Simon Fraser wrote:
>>>
On Mar 13, 2013, at 10:15 AM, Dana Jansens wrote:
>>>
On Wed, Mar 13, 2013 at 1:25 PM, Ryosuke Niwa wrote:
> On Wed, Mar 13, 2013 at 10:22 AM, Dana Jansens wrote:
>
>> On Wed, Mar 13, 2013 at 1:21 PM, Simon Fraser wrote:
>>
>>> On Mar 13, 2013, at 10:15 AM, Dana Jansens wrote:
>>>
>>> On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser
>>> wrote:
>>>
>
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 run
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_N
On Wed, Mar 13, 2013 at 10:22 AM, Dana Jansens wrote:
> On Wed, Mar 13, 2013 at 1:21 PM, Simon Fraser wrote:
>
>> On Mar 13, 2013, at 10:15 AM, Dana Jansens wrote:
>>
>> On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser wrote:
>>
>>> https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in
>>> http
On Wed, Mar 13, 2013 at 1:21 PM, Simon Fraser wrote:
> On Mar 13, 2013, at 10:15 AM, Dana Jansens wrote:
>
> On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser wrote:
>
>> https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in
>> http://trac.webkit.org/changeset/114081) added
>> internals. setBackg
On Mar 13, 2013, at 10:15 AM, Dana Jansens wrote:
> On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser 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
On Wed, Mar 13, 2013 at 12:42 PM, Simon Fraser 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
On Wed, Mar 13, 2013 at 10:04 AM, Ryosuke Niwa 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 ad
On Wed, Mar 13, 2013 at 10:04 AM, Ryosuke Niwa wrote:
> On Wed, Mar 13, 2013 at 9:59 AM, Simon Fraser wrote:
>
>>
>> On Mar 13, 2013, at 9:48 AM, Ryosuke Niwa wrote:
>>
>> On Wed, Mar 13, 2013 at 9:42 AM, Simon Fraser wrote:
>>
>>> https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in
>>> htt
On Wed, Mar 13, 2013 at 9:59 AM, Simon Fraser wrote:
>
> On Mar 13, 2013, at 9:48 AM, Ryosuke Niwa wrote:
>
> On Wed, Mar 13, 2013 at 9:42 AM, Simon Fraser wrote:
>
>> https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in
>> http://trac.webkit.org/changeset/114081) added
>> internals. setBackg
On Wed, Mar 13, 2013 at 9:59 AM, Simon Fraser wrote:
>
> On Mar 13, 2013, at 9:48 AM, Ryosuke Niwa wrote:
>
> On Wed, Mar 13, 2013 at 9:42 AM, Simon Fraser wrote:
>
>> https://bugs.webkit.org/show_bug.cgi?id=80046 (landed in
>> http://trac.webkit.org/changeset/114081) added
>> internals. setBackg
On Mar 13, 2013, at 9:48 AM, Ryosuke Niwa wrote:
> On Wed, Mar 13, 2013 at 9:42 AM, Simon Fraser 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 I
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 ca
On Wed, Mar 13, 2013 at 9:42 AM, Simon Fraser 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
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
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 wrote:
> Hi WebKittens,
>
> I'm planning to implement the canvas "op
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 , allowing optimizations at the time the canvas is
32 matches
Mail list logo
