out of bounds array read/writes could cause issues on any platform but surely all that can occur is that you corrupt video memory & potentially lock up a shader as a result ? a timeout in a faulty shader would close this security hole. a shader malfunction message could then be generated.
As of recent browsers, JavaScript isn't interpreted any more, it's natively compiled. This means we real-time 3D guys start to show some interest.
We need to do heavy lifting in client GUIs as we do a little more than configure buttons or trigger releases - think collision detection, real-time physics, procedural texture generation, etc., etc.
Re-it'll never scale - can I compile down to byte code & ship that rather than source ?
What about dynamic linking to other components or does the whole thing need compiling every run ?
There's no multi-threading so it's one core only (which is fine for now as OpenGL is single threaded anyway).
Loading complex data sets - XML is fine, but it gets bloated very quickly, especially with complex 3D models, etc.
Is there a JavaScript FastInfoSet or EXI implementation anywhere ?
In the end, whatever the API, 3D hardware draws a bunch of triangles. You can form your text as textures (images) rendered onto quads which you can then scale as required (fast) or you can form as geometry, which again you can scale (slower).
Curved surfaces are triangulated at some specified precision somewhere with the trade off more accuracy = more processing.
This functionality doesn't need to be in OGL (ES or otherwise). A graphics engine can perform the triangulation for you.
The issue right now is that WebGL engines are not mature so tech is probably of limited interest.
Lack of IE support is my largest concern. I can't see it coming any time soon either as Microsoft have invested elsewhere.
Slashdot Mirror
http://www.realityprime.com/articles/why-microsoft-and-internet-explorer-need-webgl
http://www.theregister.co.uk/2011/06/20/webgl_/
out of bounds array read/writes could cause issues on any platform but surely all that can occur is that you corrupt video memory & potentially lock up a shader as a result ? a timeout in a faulty shader would close this security hole. a shader malfunction message could then be generated.
I give a fuck.
If there is a security hole, it's unlikely to be limited to Linux (or is it ? - waiting for details)
There are still a lot of IE users out there so support on that platform would help build the business case for WebGL content.
Switching browsers is an option if it's a secure solution.
> I haven't, no, but the person who discovered the hole did, about a year ago.
details please.
> Good luck with that. Oh, and if you're using Linux with the current nVidia drivers, be careful where you navigate with WebGL enabled...
You have of course reported any known bugs to nvidia.
Smart arse responses don't help. Addressing security holes by ensuring those who need to know about problems can fix them helps.
IE is dead if MS don't implement WebGL.
Whine all you like about security flaws. It's fine - all you need is a shader validator to ensure it can't lock up.
If there are holes in drivers they should be fixed. That's not the fault of the architecture.
FF software update shipped (thank you).
Upgrade.
End of.
space elevator anchor ?
Do we have the tech to capture something like this & keep it in orbit ?
No idea what we'd do next - mine it or something, maybe use it as a platform for ISS successor.
Is this possible or would the orbit decay & it'd end up falling to earth ?
who cares - surely we should be trying to inject life into this planet.
yeah - how many polys can this baby real-time raytrace @ 60 fps ?
so that's approx. 100 Gflop per sparc cpu. (double precision?)
what can a high end xeon do ?
Real-time raytracing please.
Isn't that going backwards ?
Shouldn't the next one be f-mail ?
> and might lead to much breakage.
Why would WebGL break anything else ?
... as is the case in Gecko & Webkit ?
Encode as binary HTML (fastinfoset or exi) & transcode jpg images to jpeg-2000 (approx. 50% saving on image bandwidth vs. optimized jpeg).
Simples.
Flash is not the dominant tool for user-interface design in video games.
The dominant tools for user interface design in video games are 3dsmax, softimage & maya.
I went into the butchers the other day & bet the man behind the counter 50 quid he couldn't reach the meat on the top shelf.
He said I dunno about that, the steaks are fairly high.
Porting, not writing from scratch. In the end it's just OpenGL.
As of recent browsers, JavaScript isn't interpreted any more, it's natively compiled. This means we real-time 3D guys start to show some interest.
We need to do heavy lifting in client GUIs as we do a little more than configure buttons or trigger releases - think collision detection, real-time physics, procedural texture generation, etc., etc.
Re-it'll never scale - can I compile down to byte code & ship that rather than source ?
What about dynamic linking to other components or does the whole thing need compiling every run ?
There's no multi-threading so it's one core only (which is fine for now as OpenGL is single threaded anyway).
Loading complex data sets - XML is fine, but it gets bloated very quickly, especially with complex 3D models, etc.
Is there a JavaScript FastInfoSet or EXI implementation anywhere ?
In the end, whatever the API, 3D hardware draws a bunch of triangles. You can form your text as textures (images) rendered onto quads which you can then scale as required (fast) or you can form as geometry, which again you can scale (slower).
Curved surfaces are triangulated at some specified precision somewhere with the trade off more accuracy = more processing.
This functionality doesn't need to be in OGL (ES or otherwise). A graphics engine can perform the triangulation for you.
The issue right now is that WebGL engines are not mature so tech is probably of limited interest.
Lack of IE support is my largest concern. I can't see it coming any time soon either as Microsoft have invested elsewhere.
... and WebGL is vector based - all real-time 3D is.
Sure. It'll take a while before solid, high level WebGL engines / frameworks emerge, but there's a couple of early engines out there already.
The higher level tools / APIs / interfaces will be introduced incrementally over time.
Interesting times. Shame Microsoft aren't supporting this standard. That could really hurt their market share.