WebGL and Typed Arrays Support

[mseddon]

This is a cleaned up, squashed version of #13 adjusted according to suggestions kindly provided by @sjrd.

[sjrd]

GitHub tip: you don't need to close a pull request for this. You can simply force-push to the branch used for the PR, and the PR on GitHub will automatically update. It is better than reopening a new PR because comments are kept and correlated with the new commits for lines that have not changed.

[mseddon]

In hindsight, maybe actually providing the defined constant is not such a great idea.
The upshot is maybe the minified code would be smaller, and fwiw scalac can probably constant-fold or'd constants but perhaps these should just be = ??? instead.
Thoughts?

[sjrd]

Just make them = ???. They can still be val's (but they need an explicit type!)
(As you wrote it, the actual constant is ignored by the compiler.)

[mseddon]

Aha, good to know!

[lihaoyi]

Unfortunately, I've lost the code I used to do the original scraping. It was somewhere around 150 lines, so not particularly difficult, as CLASS.METHOD maps to https://developer.mozilla.org/en-US/docs/Web/API/CLASS/METHOD pretty cleanly and after that it's just using JSoup to guess which paragraph is the one you want.

However, given the sparsity of MDN docs for the various webgl classes and functions, it may be worth just going through and C&Ping the ones you can find. It seems tedious, but if you sit down for an hour and a half and just do it I bet you could get through almost everything.

Whatever you do, download the MDN doc bundle locally to open in your browser, because MDN itself is as slow as a three legged dog.

[mseddon]

@sjrd ah, that's handy, I cringed as I closed it for that reason :)
@lihaoyi Ok, well, that's good enough. I shall attempt something along those lines.

[mseddon]

Update: The Mozilla documentation is quite poor for WebGL (possibly not helped by the number of places the spec just links directly to the OpenGL ES 2.0 spec rather than give a definition itself), so I've opted to write them myself. Not a fun task, but at least there can be a brief one liner for every method this way.

[lihaoyi]

Looks good to me =) Have you tried it out locally? Just want to make sure that the stuff at least kind of works before we merge it

[mseddon]

It appears to work for me, but I'm happy to hold off a proper merge until I've had some time to test it over the weekend. I've not really used it much yet- so that should flush out any really silly things I may have done.

[lihaoyi]

Cool, you should be able to just publishLocal it for now, and it'll be a pretty seamless switch when we do end up merging it. Just remove the locally-published version from your .sbt/.ivy2 folder and it'll pick up the published-from-github version

[mseddon]

I've had a chance to get a few simple hello worldy examples working, (testing out array buffers, getting things actually on the screen, compiling shaders, etc.) No issues so far. Love to have a bit more time to play with it, but hey ho. Maybe good to go with a big disclaimer of bleeding edge?

[lihaoyi]

K cool, I say merge it first and fix it later then =)

[mseddon]

👍

[lihaoyi]

Feel free to send PRs for stuff that's broken; I don't expect that the
initial code dump was perfect =P With this kind of wrapper code there's no
real solution other than just fixing stuff as you find them.

On Mon, Mar 31, 2014 at 1:09 PM, mseddon notifications@github.com wrote:

[image: 👍]

Reply to this email directly or view it on GitHubhttps://github.com//pull/14#issuecomment-39135038
.

[mseddon]

Absolutely, will do! I fully intend to use it quite a bit, but unfortunately I lack the time at the moment. There will at least be one user of this part of the library at some point, however :)