Re: [webkit-dev] WebGL performance
On Oct 20, 2009, at 5:58 AM, Boris Stock wrote: I have an question regarding the WebGL implementation. It already seems to be very fast. Of course a lot of stuff is important like in native GL programs (rendering triangle stripes vs. X and stuff). But how far do you think will a future stable release of WebGL match a native GL implementation in performance? Is JavaScript speed a big show stopper there? or because the GL surface is not fullscreen and can be overlayed with other layers (which is also a big peformance impact on any system which overlays something over the opengl surface / view). At the moment there are not any significant webgl based apps (due to the current state of the spec) so we don't yet know what issues will be performance problems. On the topic of overlay performance, there is the requirement that a canvas element (WebGL or simple 2D) must composite correctly, which effectively requires a call to glReadPixels if the renderer is not able to composite on a hardware directly. There are other costs that currently don't show up as they're not implemented, most notably shader validation -- basically the UA is required to parse shaders itself and validate against a reduced subset of the GL|ES 2.0 version of GLSL (which is a subset of desktop GLSL). --Oliver ___ 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] WebGL performance
On Oct 22, 2009, at 12:38 PM, Oliver Hunt wrote: On Oct 20, 2009, at 5:58 AM, Boris Stock wrote: I have an question regarding the WebGL implementation. It already seems to be very fast. Of course a lot of stuff is important like in native GL programs (rendering triangle stripes vs. X and stuff). But how far do you think will a future stable release of WebGL match a native GL implementation in performance? Is JavaScript speed a big show stopper there? or because the GL surface is not fullscreen and can be overlayed with other layers (which is also a big peformance impact on any system which overlays something over the opengl surface / view). At the moment there are not any significant webgl based apps (due to the current state of the spec) so we don't yet know what issues will be performance problems. On the topic of overlay performance, there is the requirement that a canvas element (WebGL or simple 2D) must composite correctly, which effectively requires a call to glReadPixels if the renderer is not able to composite on a hardware directly. Note that WebCore does have support for accelerated composting of web content (see the ACCELERATED_COMPOSITING code paths), and WebGL makes use of this, so there is very little performance impact of layering content on top of a 3d canvas for platforms that have an ACCELERATED_COMPOSITING implementation. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
