Had a crash in a demo. And found the culprit. It was from having a non-zero FBO bound when doing glXDestroyContext. Which was very WTF.
Allowing images and canvases with content from outside the current domain as textures is a bad idea, as you can read them with some GLSL trickery, even if you can't use getImageData/readPixels on the context. So that needs to be fixed. Which'll make the context quite a bit less useful, but it's either that or moving to a fixed-function pipeline.
One solution would be locking the context to use the GL fixed-function pipeline once you upload a texture outside the SOP. Or have a set of trusted shader programs that you could choose from. Or force a safe subset of the shading language. (Do I smell scope creep?)
And I finally managed to write a shader that takes a long time to run and hangs the GL driver for its duration. I'm just going to call that a driver problem. If there was some easy way to compute the maximum running time of a shader and reject ones that go over the threshold of acceptability, that could be used to reject potentially nasty shaders.
But I'm still going to call that a driver problem.
art with code
2009-03-16
Subscribe to:
Post Comments (Atom)
Blog Archive
-
▼
2009
(84)
-
▼
March
(15)
- More ATI Linux debugging
- Why you might like Canvas 3D (or not)
- More Canvas 3D tests, preliminary bandwidth benchmark
- Linux + ATI + Canvas 3D = GLX 1.3, please?
- GLSL parsing
- Bad juju Sunday
- JS xpconnect call overhead
- My fork of the Canvas 3D Mercurial repo
- Fuzz tests, texture methods, GLSL ES pondering
- Canvas 3D uniforms, glGetError exception throwing
- Canvas 3D high-priority tests done
- Still alive
- 4x4 matrix multiplication in JavaScript vs C
- Canvas 3D tests update
- The anatomy of the Canvas 3D extension
-
▼
March
(15)
No comments:
Post a Comment