Maybe I should complain this in a different threads, but recently the commit
bot waiting time is way too long. Several times a patch of mine got the r+
and cq+ and it landed two days later. This is really frustrating.
I am very tempted to use svn directly to commit patches, but that means the
pa
Currently for a function's signature in WebKit, if an argument's type
is a wrapper type (those JS objec ts that wrap c++ objects, for
example, JSWebGLProgram, JSCSSRule, etc.) and if the input object's
type does not match the signature, the input is casted to null and no
TypeError is raised.
Even
irst one I looked at was CanvasRenderingContext2D::drawImage). Can you go
> into more detail about why the WebGL bindings need to be more strict than
> the rest of the codebase?
> -Sam
>
> On Wed, Aug 11, 2010 at 7:06 PM, Mo, Zhenyao wrote:
>>
>> Currently for a function&#
ments=Raise]. Historically, we've been lax about
> missing arguments. I think the specs want us to be stricter, but last
> time we discussed the topic, the read I got was that the compatibility
> pain might not be worth the benefit.
>
> Adam
>
>
> On Wed, Aug 11, 2010 at 7:06 PM
0 at 11:10 PM, Mo, Zhenyao wrote:
> Actually it's a different issue. What we want to do is not enforcing
> full arguments, but if an input argument is the wrong type, we raise a
> TypeError.
>
> Mo
>
> On Wed, Aug 11, 2010 at 7:13 PM, Adam Barth wrote:
>>
That should work too.
mo
On Thu, Aug 12, 2010 at 3:24 AM, Dumitru Daniliuc wrote:
>> so i think we just need to change toJS/toV8...
>
> sorry, i meant to(), not toJS/toV8.
>
>>
>> dumi
>>
>> On Wed, Aug 11, 2010 at 11:10 PM, Mo, Zhenyao wrote:
>>&g
Hardly. Right now we already do the type checking in the generated
toType(argument) functions. Instead of casting to null, we throw a
TypeError, which adds no extra cost if the type is correct.
Besides, where I looked, after toType(argument) call, exception is
checked. Only that currently toTyp
t;
>> It would be possible to add support for another extended attribute to
>> the code generators and annotate all of the methods in
>> WebGLRenderingContext.idl, but I really think the default behavior
>> should be changed.
>>
>> -Ken
>>
>> On Thu, Aug
Just make sure if WebGL is on, TypedArray is always there.
Mo
On Thu, Dec 23, 2010 at 10:23 AM, Jian Li wrote:
> Sounds like a good idea. I am going to add TYPED_ARRAY guard for this.
> Thanks,
> Jian
>
> On Thu, Dec 23, 2010 at 8:13 AM, Chris Marrin wrote:
>>
>> On Dec 22, 2010, at 5:34 PM, Ji
Hi,
I am doing some refactoring in WebGL, and it will touch almost every
function in WebGLRenderingContext and other classes start with WebGL*
under WebCore/html/canvas.
Can I ask that for next Monday and Tuesday, do not touch these files
until my patch lands?
Otherwise merge will be a big pain.
Hi,
I am working on improving WebGL texture uploading performance. At the
moment, for each texture loaded from HTMLImageElement, images are
always decoded twice: the first pass is regular decoding, the second
pass is for WebGL only. The reason is that for WebGL, we sometimes
want the raw RGBA da
We already have a mechanism installed to handle extensions. Look at
WebCore/platform/graphics/Extension3D.h
And we have chromium specific ones in
WebCore/platform/graphics/chromium/Extension3DChromium.h
Develop another mechanism to handle GL extensions would cause a mess.
You should look into th
Angle in webkit is only the shader translator, which doesn't change
very often, whereas the main Angle (GLES simulation on top of D3D) is
still under active development.
We should update webkit Angle from time to time, but if it's outdated,
no need to be alarmed. We definitely don't need to updat
In StringHash.h line 89
StringHash::hash(const String& key) { return key.impl()->hash(); }
so it assumes String::impl() never returns NULL.
However, I encountered a case where String::impl() is NULL, thus, crash.
So what's wrong here?
___
webkit-dev m
at 5:14 PM, Eric Seidel wrote:
> Why are you hashing a null string? aka String(). We could make that
> function support null strings, but I guess it hasn't needed to until
> now.
>
> On Wed, Apr 13, 2011 at 5:00 PM, Mo, Zhenyao wrote:
>> In StringHash.h line 89
>>
:32 PM, Mo, Zhenyao wrote:
>
> What value should we return for hash(NULL)?
>
> From the top of the file:
> // The hash() functions on StringHash and CaseFoldingHash do not support
> // null strings. get(), contains(), and add() on HashMap StringHash>
> // cause
My patch added a few new files in WebCore. Somehow I couldn't get the QT
port to link.
>From the linking error, it seems the source files are not compiled.
So besides adding the files in WebCore.gypi for chromium port and
WebCore.xcodeproj for Mac port, are there other things I need to do to add
17 matches
Mail list logo
