I submitted a pull request
https://github.com/kripken/emscripten/pull/1999that fixes a few of the
issues related to GL emulation
prepareClientAttributes, and it adds a few diagnostic prints when -s
GL_ASSERTIONS=1 is used to detect some unsupported cases. It might be
worthwhile to check that code out to see if it helps in debugging.

   Jukka


2014/1/7 Jukka Jylänki <[email protected]>

> Ah now I notice that my fix for that bindAttribLocation was already done,
> but it's pending in an unmerged pull request here:
> https://github.com/juj/emscripten/commit/0cd4d2034bbb0cf834ae1e84f81bef4e8f100f41
>
> As for GL emulation, it's tricky to say where the issue is, since the GL
> emulation is a partial one and not complete. I've been digging through the
> GL emulation codebase for a while now, and here's some random observations
> of things that I've observed to be lacking:
>    - Rendering from client-side vertex attributes assumes that all
> attributes are multiples of 4 bytes (4xu8 RGBA or float elements).
>    - The emulation code only supports two vertex pointer layouts: all data
> is either planar in their separate CPU-side buffers, or all data is
> interleaved in a single CPU-side buffer. Weird hybrid scenarios, like some
> attributes being in GL VBOs and others being in CPU side, or some
> attributes being interleaved while keeping others planar will probably not
> work.
>     - The code assumes that the presence of what's bound to
> GL_ARRAY_BUFFER _at glDrawArrays()_ time dictates whether user is doing CPU
> or GPU -side buffer rendering, but this is not quite correct, the proper
> way would be to remember what was bound at
> glVertex/Normal/Color/TexcoordPointer() call time.
>    - As you noticed above, there is a fixed-size limit set to max. size of
> a vertex buffer.
>
> The Regal emulation project has had some success on Emscripten so far -
> perhaps using that for emulation could work out better. Apart from that,
> you could try using AMD CodeXL (gDEBugger) or similar to trace through GL
> calls that the browser sends to the GL driver, and try to compare to your
> native build to see if that could give ideas on what's missing. That can be
> a bit of a long shot, but if nothing else works, perhaps worth trying.
>
>     Jukka
>
>
> 2014/1/6 wolfviking0 <[email protected]>
>
>> Hi Floh,
>>
>> I don't try WebGL debug tools just, the GL_DEBUG=1 inside emscripten :(,
>> I will try that, thanks.
>>
>> I try an other sample really similar using webcl and drawing an list of
>> GL_POINTS and it works perfect (
>> https://twitter.com/wolfviking0/status/419523736341975040/photo/1). I am
>> not sure why this give trouble ... must be a little things ...
>>
>> I will check Chrome Canary. Again thanks.
>>
>> Tony
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to