[webkit-dev] Sharing the OpenGL GraphicsContext3D implementation

[Maciej Stachowiak]

On Feb 22, 2011, at 1:01 PM, Oliver Hunt wrote:

> I agree.  My hope was always that the OpenGL backend could be shared among all the webkit ports, my only suggestion is that rather than having a separate OpenGLExtensionsFunctions class, I think we probably want something like
> 
> GraphicsContext3DOpenGL.{h,cpp} for all the common logic
> 
> and then
> 
> GraphicsContext3DOpenGL{Gtk, Mac, Wx, Posix, ...}.cpp
> 
> etc
> 
> To implement the functions that can't be shared.
> 
> This would be in keeping with our normal design approach for using system platform specific APIs.

The availability of particular OpenGL extensions likely does not correlate with WebKit port identity, so I'm not sure that particular approach is workable. This is likely to be a matter of the underlying OS, and in some cases may need to be handled at runtime, not just compile time. So Zan's original suggestion sounds more plausible to me.

 - Maciej

> 
> --Oliver
> 
> 
> On Feb 22, 2011, at 12:53 PM, Zan Dobersek wrote:
> 
>> Hi,
>> 
>> I'm writing this mail in order to propose changes that would make the OpenGL implementation of the GraphicsContext3D a lot easier to share between the Mac and Gtk port.
>> 
>> Currently the mentioned implementation is only used by the Mac port. The Gtk port is also interested in using this implementation and there is already a patch available in bug #31517[1] by Martin Robinson that brings the WebGL functionality to daylight.
>> 
>> There is, however, the issue of the OpenGL extensions functions. Current OpenGL implementation is Mac-only, and Mac port has a specific set of extensions functions available. The same cannot be said for the Gtk port, which can end up having extensions functions available that do not have the same extension suffix as the Mac port's functions (EXT vs ARB). Because of that the current proposed implementation acquires addresses of the OpenGL extensions functions and then uses shims to make the GraphicsContext3D work.
>> 
>> I recommend a new class to be created for these two ports to use, named something like OpenGLExtensionsFunctions. Extensions-specific functions in the GraphicsContext3D class would then be replaced with calls to the corresponding functions in this class, for example OpenGLExtensionsFunctions::blitFramebuffer instead of current ::glBlitFramebufferEXT. Implementation for the Mac port would be simple, passing arguments on to functions that are currently used in the GraphicsContext3D class. Gtk port's implementation would simply call the functions that were acquired, with no need to depend on shims.
>> 
>> Modifying the OpenGL implementation of the GraphicsContext3D class in this way would ease the use of it for the Gtk port and perhaps any other port that would go on to use this implementation with no damage to the Mac port.
>> 
>> I'd like to hear what Mac folks think of this approach and if there are any other ideas that address this problem.
>> 
>> Regards,
>> Zan Dobersek
>> 
>> [1] https://bugs.webkit.org/show_bug.cgi?id=31517
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110222/ffb00157/attachment.html>