Take all of the following with a grain of salt because I'm just coming up to speed on it myself, but...
The only part of that discussion I have problems with is "Heck, we’re even disabling WebGL for most Linux drivers, last I checked…". The statement implies that WebGL is a relatively easy thing to support, and if *that* has problems then everything *else* must be worse.
I believe the reality is quite different. WebGL is relatively new, and its implementation seems to differ significantly between browser implementations. Some (Chromium for example) can run WebGL over regular GL, while most of the others require a GL ES implementation because they pass the WebGL validation work down to the graphics driver and WebGL basically corresponds with GL ES (2.0, I think) rather than GL.
GL ES implementations are relatively new on the proprietary drivers, and are still a work in process on most of the open source drivers. There is considerable work being done, but GL ES and particularly co-existence of GL and GL ES APIs is probably the closest thing to "bleeding edge" in the entire open source stack.
So... bottom line is that there probably are challenges running WebGL on many of the drivers today as a consequence of the relative newness and volatility of the GL ES implementation, but it's also an area where work is being done and interest is growing. The discussion following that post seems to suggest that Chromium/Chrome still has an advantage for running WebGL because of its ability to run over a GL stack rather than relying on a "tight and robust" GL ES implementation to perform the WebGL validation work.
I'm sure the developers are seeing other issues as well, but those are going to be more in the "both sides gotta agree on a core set of driver functionality to use, upper layers should use that functionality, and devs will make sure it works" department. I don't know if bugs are being filed against the drivers as problems are seen during browser development, but that would obviously help as well.
can somebody explain where exactly the problem is here???
i mean we have gl games and stuff that work
Totally different ball game. Fullscreen gl apps/games are different from regular apps using gl inline with regular code. Firefox devs are no doubt probably invoking apis a that are rarely used and rarely tested.
wasn't there a opengl es state tracker for Gallium implemented some time ago???
Yes, as a build option for Mesa. It is still undergoing fairly major changes, however, in order to allow simultaneous support for GL and GL ES APIs (if I understand it correctly).
Originally Posted by 89c51
and doesn't that means (if yes to the above) that all drivers using g3d can run webgl???
Once the implementation has been tested and fixed as necessary on each hardware platform, and the both sides of the API have been tweaked as necessary to "follow the rules", yes. It's just that this is one of the newest and least used areas of the open source graphics stack.
It seems like most people in this thread are running Windows or MacOS.
Have you ever bothered peeping into freedesktop's bugzilla and counting bugs filed against X.org server, MesaGL and other components? Literally there are hundreds if not thousands of bug reports and most of them have next to zero activity.
E.g. you still cannot run both recent Unigine demos on Intel drivers. Also it's worth noting that Intel drivers have abysmal OpenGL performance in many games (up to ten times slower than in Windows).
Or take for instance this core X.org bug. It's absurd thinking that any Windows or MacOS release could have been made available with such a bug. Even though X.org project lacks manpower I fail to see why such critical bug reports don't have the utmost attention.
X.org project and open source X.org video drivers severely lack manpower. Alas, I don't see it changing in the foreseeable future.