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
Re: [webkit-dev] beforeload link (esp rel prefetch)
I think that adding beforeload to META-based prefetch and icon types makes a lot of sense. For subresource rel type, we may want to register it first, as mentioned by Julian. Steps 3-5 obviously depend on whether we want to proceed with adding support for the Link header field, which I'm not sure if it's got much support on webkit-dev. - WBR, Alexey Proskuryakov 22.02.2011, в 15:11, Gavin Peters (蓋文彼德斯) написал(а): Hi! I'm returning to this work now, and I see that folks have been quiet about this since I posted my plan. Here's how I'm going to proceed: Step 1: I will add beforeload to prefetch icon rel types. Expect a CL for this soon. Step 2: I will add a new subresource rel type, which will have higher priority than prefetch, otherwise be the same. Step 3: We land bug 51941, which factors out the cache/LinkLoader.cpp from html/HTMLLinkElement.cpp Step 4: We land the Link header parser directly (bug 51940) Step 5: Add beforeload events to the Link header? Comments? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
2011/2/23 Alexey Proskuryakov a...@webkit.org: I think that adding beforeload to META-based prefetch and icon types makes a lot of sense. For subresource rel type, we may want to register it first, as mentioned by Julian. Looks like Gavin already registered it on 5 November 2010, so we're all set in that regard. Adam Steps 3-5 obviously depend on whether we want to proceed with adding support for the Link header field, which I'm not sure if it's got much support on webkit-dev. - WBR, Alexey Proskuryakov 22.02.2011, в 15:11, Gavin Peters (�w文彼德斯) написал(а): Hi! I'm returning to this work now, and I see that folks have been quiet about this since I posted my plan. Here's how I'm going to proceed: Step 1: I will add beforeload to prefetch icon rel types. Expect a CL for this soon. Step 2: I will add a new subresource rel type, which will have higher priority than prefetch, otherwise be the same. Step 3: We land bug 51941, which factors out the cache/LinkLoader.cpp from html/HTMLLinkElement.cpp Step 4: We land the Link header parser directly (bug 51940) Step 5: Add beforeload events to the Link header? Comments? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
23.02.2011, в 17:06, Adam Barth написал(а): I think that adding beforeload to META-based prefetch and icon types makes a lot of sense. For subresource rel type, we may want to register it first, as mentioned by Julian. Looks like Gavin already registered it on 5 November 2010, so we're all set in that regard. I've been looking at http://www.iana.org/assignments/link-relations/link-relations.xml and http://paramsr.us/tracker/issue?@sort=-activity@search_text=@dispname=Показать%20все@filter=@group=registry@columns=id,activity,title,creator,assignedto,status@pagesize=50@startwith=0status=-1,1,2,3registry=1, and don't see subresource there. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
2011/2/23 Alexey Proskuryakov a...@webkit.org: 23.02.2011, в 17:06, Adam Barth написал(а): I think that adding beforeload to META-based prefetch and icon types makes a lot of sense. For subresource rel type, we may want to register it first, as mentioned by Julian. Looks like Gavin already registered it on 5 November 2010, so we're all set in that regard. I've been looking at http://www.iana.org/assignments/link-relations/link-relations.xml and http://paramsr.us/tracker/issue?@sort=-activity@search_text=@dispname=Показать%20все@filter=@group=registry@columns=id,activity,title,creator,assignedto,status@pagesize=50@startwith=0status=-1,1,2,3registry=1, and don't see subresource there. That's related to the following issue in the HTML working group: http://www.w3.org/html/wg/tracker/issues/27 The HTML5 spec currently refers to http://wiki.whatwg.org/wiki/RelExtensions, which is where Gavin registered the relation. In any case, we can register them in both places. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Leopard Debug
As far I as I can tell, Leopard Debug is not consistently green: http://build.webkit.org/waterfall?show=Leopard%20Intel%20Debug%20(Build) In fact, it's been failing to build much more often than not for an extended period of time (i.e., several weeks). Based on these observations, it should not be a core builder. We can add it back to the set of core builders when it's consistently green again. To be concrete, shall we say building cleanly for a week? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] when will pages group into different PageGroup
I'm reading source about Page class.I found there's related class named PageGroup,which seems to group different pages into different group by name. Different PageGroup has different user script and GroupSetting. I wonder when will the page group into different PageGroup. If there's two apps based on webcore(one is browser,maybe),does this means there's two PageGroup? In my option,GroupSetting and user script is same for all the pages in browser. Another question,shouldTrackVisitedLinks is a class member.If there's two apps,and one want to disable visistedTrack(call setShouldTrackVisitedLinks(false),it will influence the behavior of another app? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
