Menu
▾
▴
#106 WebGL not Working
Since a few builds back. Not sure when. WebGL not working on sites... :(
http://alteredqualia.com/three/examples/webgl_pasta.html
http://arodic.github.io/p/jellyfish/
Wish I had more info to help out... ;)
That's most probably a hardly avoidable side effect of little endian typed arrays - unfortunately there's a lot of JavaScript code nowadays that requires little endian memory accesses.
The upcoming 603 series is even more broken and I don't think I can fix that.
I read this has become a problem on PPC JS interpreters. But I am wondering why. If the code is all script then it shouldn't generate little endian data. The only reason this should be hapening is with reading in external binary files. And scripts shouldn't be reading in binary without good reason. Why are the arrays needed to be in little endian? In this day and age code should be truely portable even if all popular computers have backwards CPUs. Despite numerous platforms available we've gone back to a "Windows only" type of computer world where only one OS and CPU has real support.
I take it the GCC -mlittle-endian switch is no good? I tried it once on a LE specific subroutine for some code but didn't see any difference.
Last edit: Damien Stewart 2017-03-14
Well, JavaScript is used more and more for working with binary data; facebook parses (and even modifies?) binary image data using JavaScript, I also know of web sites that implement their own cryptographic library in JavaScript.
But the fact of processing binary data doesn't imply endianness issues - endianness issues arise for example when reading the first four bytes of binary data at once but in fact you later on need to parse that data byte by byte; the byte order does matter in cases like this. JavaScript typed array views are the part of the language that make endianness issues possible - although that's not there purpose.
Okay think I understand. So it's kind of like an fread() where you can specify a long word that is tied to the binary format read in? Reading in four bytes to access by byte later shouldn't matter usually as they normally would be read in by order. So it seems they have put effort into malking this hard. At least to me, since you would expect a WYSIWG orientation, not for your data to be reversed. By now I woild have expected C/++ compilers and languages like JS to support attributes specifying endianness.
Using fread the bytes obviously arrive in the order they have been stored. But that's exactly the problem as it makes a huge difference if you consider the first (big endian) or the last (little endian) of four bytes as the most significant byte of a 32 Bit value.
Endianness nearly always makes a difference whereever a byte stream needs to be parsed. And with typed arrays that possbility has arrived in the JavaScript language - including the inherent endianness problem.
Whereever a programming language offers the possibility to reinterpret a stream of bytes you have to take care of the endianness of the CPU that will execute your code.
And unfortunately (for us PowerPC users) little endian byte order has come to be the only one programmers will normally consider. The best way to face that problem is to simply emulate little endian byte on big endian CPUs.
Oh Well.. If I need to see something on WebGL, I'll crank up Ten4Fox and wait for it to load... :(
Thanks for all your work keeping this updated.
Last edit: Roger Hodge 2017-03-06
As far as I know there's no WebGL support at all in TenFourFox because 10.4 doesn't support OpenGL 2.
Yeah, You're right. I can use original Safari for it. Still seems to work on my site... :)
And even then you'll only have WebGL support when you've installed Leopard WebKit as replacment for the latest release shipped by Apple (at that time WebGL didn't exist yet).