Hello Jarkko, I think this issue is just a design choice. In Chromium's port, if certain GL functions are not supported natively, it uses the software emulated part to fill out the unsupported part.
I can understand that mixing native GL functions and emulated ones is more complex, and developers may decide that it is not worse to spend lots of time to implement such a mixing infrastructure in the current stage. But it cannot be claimed that supporting partial set of GL function is not achievable. We just can say that the mixing mechanism would not supported currently since we don't want to incorporate more architectural complexity. Sincerely, Joseph 2011/5/11 Jarkko Sakkinen <[email protected]>: > Hi Joseph, > > On Thu, May 5, 2011 at 8:35 AM, Joseph Tsai <[email protected]> wrote: >> Digging in sources, I found that QtWebKit's port would query available >> OpenGL functions by GraphicsContext3DInternal::getProcAddress() from >> DLL (in WebCore/platform/graphics/qt/GraphicsContext3DQt.cpp). Current >> implementation is that: If certain OpenGL function is not available, >> the WebGL feature is disabled (in the constructor of class >> GraphicsContext3DInternal). For example, glBlendEquation() is not >> supported in my Windows XP platform, although I don't need this >> function, WebGL is still disabled in QtWebKit. > > You probably mean glBlendEquationSeparate() (possibly with EXT or ARB) > right? glBlendEquation() is supported by practically all OpenGL > implementations. > >> WebGL for QtWebKit does not support partial set of OpenGL functions, >> this implementation is different from Chromium's port. >> (Chromium can run WebGL under my Windows XP) > > This is bit problematic. WebGL 1.0 standard requires certain set of functions > to be available. So allowing to initialize would not be compatible with the > standard. > > BR, Jarkko > _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
