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
