[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Minefield brings system to halt



Hi,

recently, I tried it again with Minefield. The mentioned crash didn't occur
again, however, most of the X3DOM models don't render there - albeit
everything works fine in Chrome Beta/ Chromium/ Firefox Beta.

The problem seems to be caused by some changed behavior in the Array object,
and not in WebGL, so probably this list might be wrong. However, perhaps it's
related with TypedArray or so...

The problem is like follows. In my code I have something like this:

MFInt32.prototype = new Array;
[...]
MFInt32.prototype.foo = function() {};

Which works fine everywhere except for Minefield, where it only works without
the latter line of code (i.e. without 'MFInt32.prototype.foo=...'). Otherwise,
the array can't be set.
So I wonder if this is forbidden now due to some spec changes or if it is just
a bug. For the case it's a bug, I've attached a little test.

Bye
Yvonne

Am Di, 21.09.2010, 17:55, schrieb Benoit Jacob:
> ----- Original Message -----
>> Just to clarify, there were two problems: one with shading in general,
>> this now works with disabling the validator in Firefox Beta. The other
>> one are these "need at least 12 bytes, but have only 0 ..." messages
>> in
>> combination with the system halt occurring after a while in Minefield
>> nightly - this still exists :(
>
> Ah, I didn't realize that the freeze still existed.
>
> I will have a look at your suggestion in your previous email.
>
> Benoit
>
>>
>>
>> Am 21.09.2010 17:47, schrieb Benoit Jacob:
>> > Yes, but that is precisely what is (in principle) implemented in the
>> > code that I pasted in this thread. Since disabling the shader
>> > translator fixed it for Yvonne, we concluded that the problem was
>> > probably with ANGLE. In principle the issues with attrib 0 on
>> > desktop GL are solved in Minefield (and have been solved for a
>> > longer time in WebKit).
>> >
>> > Benoit
>> >
>> > ----- Original Message -----
>> >> I raised a problem a few weeks ago where attrib 0 has to be bound
>> >> to
>> >> the vertex position. I got around this by simply ensuring that I
>> >> always
>> >> bind vertex position to attrib 0. Ken Russell/Vlad discussed this
>> >> and
>> >> I
>> >> believe their intention was to ensure that ES2 behavior applied
>> >> (which
>> >> allows any attribute to be bound to 0). I haven't removed my patch,
>> >> so
>> >> I've no idea if this was resolved. If you search the list you
>> >> should
>> >> find the conversations.
>> >>
>> >> HTH
>> >>
>> >> Alan
>> >>
>> >>
>> >> On 9/21/2010 8:23 AM, Benoit Jacob wrote:
>> >>> ----- Original Message -----
>> >>>> Hi Benoit,
>> >>>>
>> >>>> thank you for your fast response.
>> >>>>
>> >>>> Am 21.09.2010 16:30, schrieb Benoit Jacob:
>> >>>>> Another thing that's worth trying is setting
>> >>>>> webgl.shader_validator
>> >>>>> to false, to see if it's an issue with our ANGLE copy or the way
>> >>>>> that we're using it.
>> >>>> I first started testing in Firefox Beta: when disabling the
>> >>>> shader
>> >>>> validator both mentioned demos (the shadows and the cube map/
>> >>>> multi-texture shader) both work again as expected :-) (though the
>> >>>> console still tells s.th. about "been bound to a different
>> >>>> target").
>> >>>>
>> >>>> This really hints to an ANGLE problem, because I then double
>> >>>> checked
>> >>>> my
>> >>>> Chromium settings and remembered that there I have had to
>> >>>> activate
>> >>>> the
>> >>>> "--use-gl=desktop" flag to make it work (Chrome Beta is ok
>> >>>> without)...
>> >>> Ah! Very interesting.
>> >>>
>> >>> I would like to report to ANGLE but this is quite nontrivial as we
>> >>> would probably need a small testcase. If we could bisect it to a
>> >>> precise shader, that would probably help!
>> >>>
>> >>> Alternatively, there's a good hope that some ANGLE devs are
>> >>> reading
>> >>> this list anyway ... ;-)
>> >>>
>> >>>> Concerning NeedFakeVertexAttrib0() I'd assume that this check is
>> >>>> simply
>> >>>> too vague,
>> >>> Well the check that results in the error message is in the part of
>> >>> the code that I elided. There are still questions that could not
>> >>> be
>> >>> easily explained by a bug there:
>> >>>    - why does the VBO have no data when drawElements is called? Is
>> >>>    it
>> >>>    a race condition in loading resources, as was suspected last
>> >>>    week
>> >>>    on this list about the Caves demo?
>> >>>    - why does drawElements get called to draw only 1 vertex?
>> >>>
>> >>> Cheers,
>> >>> Benoit
>> >>>
>> >>>> since there hasn't been any problem with rendering before,
>> >>>> at
>> >>>> least on those machines with a fairly good GPU -- even in the
>> >>>> case
>> >>>> attribute 0 wasn't set (what I admittedly don't know because I
>> >>>> haven't
>> >>>> checked it as we dynamically assign the locations based on the
>> >>>> name
>> >>>> of
>> >>>> the respective attribute in the shader via getAttribLocation).
>> >>>>
>> >>>> Cheers
>> >>>> Yvonne
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Yvonne Jung
>> >>>> Fraunhofer-IGD | Tel.: ++49-6151-155-290
>> >>>> Fraunhoferstr. 5 | Fax.: ++49-6151-155-196
>> >>>> 64283 Darmstadt | email: yvonne.jung@igd.fraunhofer.de
>> >>>> Germany | http://www.igd.fhg.de/igd-a4
>> >>> -----------------------------------------------------------
>> >>> You are currently subscribed to public_webgl@khronos.org.
>> >>> To unsubscribe, send an email to majordomo@khronos.org with
>> >>> the following command in the body of your email:
>> >>>
>>
>>
>> --
>> Yvonne Jung
>> Fraunhofer-IGD | Tel.: ++49-6151-155-290
>> Fraunhoferstr. 5 | Fax.: ++49-6151-155-196
>> 64283 Darmstadt | email: yvonne.jung@igd.fraunhofer.de
>> Germany | http://www.igd.fhg.de/igd-a4
>


---
Yvonne Jung
Fraunhofer-IGD    | Tel.: ++49-6151-155-290
Fraunhoferstr. 5  | Fax.: ++49-6151-155-196
64283 Darmstadt   | email: yvonne.jung@igd.fraunhofer.de
Germany           | http://www.igd.fhg.de/igd-a4
Title: Array broken