Re: [webkit-dev] Sharing the OpenGL GraphicsContext3D implementation
We already have a mechanism installed to handle extensions. Look at WebCore/platform/graphics/Extension3D.h And we have chromium specific ones in WebCore/platform/graphics/chromium/Extension3DChromium.h Develop another mechanism to handle GL extensions would cause a mess. You should look into the above mentioned classes and see if they can be used in Gtk easily. If not, then we should look into refactoring it instead creating something totally new. Mo On Tue, Feb 22, 2011 at 12:53 PM, Zan Dobersek zandober...@gmail.com 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing the OpenGL GraphicsContext3D implementation
Forgot to reply to all, sorry for the mess, webkit-dev :/ On Wed, Feb 23, 2011 at 7:15 PM, Mo, Zhenyao zhen...@gmail.com wrote: You could just create a new Extension3DOpenGLGtk class that inherits from Extension3DOpenGL, and do your specific thing there. The goal here is to make OpenGL GC3D shareable, so using Extensions3D calls to extensions functions in that implementation would be replaced with something like getExtensions()-extensionsFunction(). I don't see this being possible without adding prototypes to Extensions3D class, not without some dirty hacks that cast Extensions3D class to an Extensions3DOpenGLGtk class in specific cases, or similar. If you don't mind, please add me (z...@google.com) and Ken (k...@google.com) to the cc list on the bug for this issue. Created bug #55072[1] fon this issue and added both to the CC list. [1] https://bugs.webkit.org/show_bug.cgi?id=55072 Zan (Below are the two messages in their entirety that weren't sent to the list.) On Wed, Feb 23, 2011 at 7:15 PM, Mo, Zhenyao zhen...@gmail.com wrote: You could just create a new Extension3DOpenGLGtk class that inherits from Extension3DOpenGL, and do your specific thing there. If you don't mind, please add me (z...@google.com) and Ken (k...@google.com) to the cc list on the bug for this issue. Thank you. Mo On Wed, Feb 23, 2011 at 9:06 AM, Zan Dobersek zandober...@gmail.com wrote: On Wed, Feb 23, 2011 at 3:59 PM, Mo, Zhenyao zhen...@gmail.com wrote: We already have a mechanism installed to handle extensions. Look at WebCore/platform/graphics/Extension3D.h And we have chromium specific ones in WebCore/platform/graphics/chromium/Extension3DChromium.h Develop another mechanism to handle GL extensions would cause a mess. You should look into the above mentioned classes and see if they can be used in Gtk easily. If not, then we should look into refactoring it instead creating something totally new. To use the Extensions3D class, it should be modified, adding ~90 function prototypes to the class for Mac and Gtk platforms only, and then implement those in separate files, e.g. platform/graphics/mac/Extensions3DOpenGLMac.cpp (or .mm, dunno) and platform/graphics/gtk/Extensions3DOpenGLGtk.cpp. That's basically already being done for the glBlitFramebuffer and glRenderbufferStorageMultisample functions. If the Mac developers give a green light I can come up with a patch containing these changes and providing a Mac implementation in a reasonably short time. Zan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing the OpenGL GraphicsContext3D implementation
On Wed, Feb 23, 2011 at 12:40 PM, Zan Dobersek zandober...@gmail.com wrote: Forgot to reply to all, sorry for the mess, webkit-dev :/ On Wed, Feb 23, 2011 at 7:15 PM, Mo, Zhenyao zhen...@gmail.com wrote: You could just create a new Extension3DOpenGLGtk class that inherits from Extension3DOpenGL, and do your specific thing there. The goal here is to make OpenGL GC3D shareable, so using Extensions3D calls to extensions functions in that implementation would be replaced with something like getExtensions()-extensionsFunction(). I don't see this being possible without adding prototypes to Extensions3D class, not without some dirty hacks that cast Extensions3D class to an Extensions3DOpenGLGtk class in specific cases, or similar. The Extensions3D class already has prototypes for all of the extensions it supports, and more could be added for the entry points in GraphicsContext3D which are not in core OpenGL. There are also already per-port implementations of this class, so Gtk could handle looking up the extensions differently than the Mac platform, for example. I think Mo's suggestion would work; take a closer look at the code. -Ken If you don't mind, please add me (z...@google.com) and Ken (k...@google.com) to the cc list on the bug for this issue. Created bug #55072[1] fon this issue and added both to the CC list. [1] https://bugs.webkit.org/show_bug.cgi?id=55072 Zan (Below are the two messages in their entirety that weren't sent to the list.) On Wed, Feb 23, 2011 at 7:15 PM, Mo, Zhenyao zhen...@gmail.com wrote: You could just create a new Extension3DOpenGLGtk class that inherits from Extension3DOpenGL, and do your specific thing there. If you don't mind, please add me (z...@google.com) and Ken (k...@google.com) to the cc list on the bug for this issue. Thank you. Mo On Wed, Feb 23, 2011 at 9:06 AM, Zan Dobersek zandober...@gmail.com wrote: On Wed, Feb 23, 2011 at 3:59 PM, Mo, Zhenyao zhen...@gmail.com wrote: We already have a mechanism installed to handle extensions. Look at WebCore/platform/graphics/Extension3D.h And we have chromium specific ones in WebCore/platform/graphics/chromium/Extension3DChromium.h Develop another mechanism to handle GL extensions would cause a mess. You should look into the above mentioned classes and see if they can be used in Gtk easily. If not, then we should look into refactoring it instead creating something totally new. To use the Extensions3D class, it should be modified, adding ~90 function prototypes to the class for Mac and Gtk platforms only, and then implement those in separate files, e.g. platform/graphics/mac/Extensions3DOpenGLMac.cpp (or .mm, dunno) and platform/graphics/gtk/Extensions3DOpenGLGtk.cpp. That's basically already being done for the glBlitFramebuffer and glRenderbufferStorageMultisample functions. If the Mac developers give a green light I can come up with a patch containing these changes and providing a Mac implementation in a reasonably short time. Zan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Sharing the OpenGL GraphicsContext3D implementation
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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing the OpenGL GraphicsContext3D implementation
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.
--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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing the OpenGL GraphicsContext3D implementation
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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
