The simple teapot demo can be found in https://github.com/mtrofin/wasm-android-demo .

Adding caching would be easy, but it would be helpful to know why it's slow. Is it just that it has a bunch of vtable lookups? If so, could that be problematic elsewhere as well? 

Mircea, could you provide the sub-profile underneath this method?

Here it goes. I think it may be more productive if I uploaded the traces, but they are kind of large, so it will be a bit.

Total Samples	Running Time	Self (ms)		Symbol Name
33126	3312.6ms    4.2%	253.3	 	                                                                           blink::ScopedRGBEmulationColorMask::ScopedRGBEmulationColorMask(gpu::gles2::GLES2Interface*, unsigned char*, blink::DrawingBuffer*)
23959	2395.9ms    3.0%	53.9	 	                                                                            blink::DrawingBuffer::requiresAlphaChannelToBePreserved()
23254	2325.4ms    2.9%	125.9	 	                                                                             blink::DrawingBuffer::defaultBufferRequiresAlphaChannelToBePreserved()
21991	2199.1ms    2.8%	111.3	 	                                                                              blink::DrawingBuffer::getMultisampledRenderbufferFormat()
20814	2081.4ms    2.6%	190.8	 	                                                                               content::WebGraphicsContext3DProviderImpl::getCapabilities()
18904	1890.4ms    2.4%	87.9	 	                                                                                content::ContextProviderCommandBuffer::ContextCapabilities()
16706	1670.6ms    2.1%	182.0	 	                                                                                 base::ThreadCheckerImpl::CalledOnValidThread() const
5240	524.0ms    0.6%	23.2	 	                                                                                  base::AutoLock::AutoLock(base::Lock&)
5008	500.8ms    0.6%	15.5	 	                                                                                   base::AutoLock::AutoLock(base::Lock&)
4852	485.2ms    0.6%	139.4	 	                                                                                    base::Lock::Acquire()

https://drive.google.com/drive/folders/0BzRscPk0VolKQ2FxZ0VqOVpPcTQ?usp=sharing

You're running with DCHECKs, which are known to have a significant impact on performance of GPU related code: 
"""
gpu::Capabilities ContextProviderCommandBuffer::ContextCapabilities() {
  DCHECK(bind_succeeded_);
  DCHECK(context_thread_checker_.CalledOnValidThread());
"""

Turn them off and let us know if there's still a problem.

Indeed - after explicitly setting is_debug to false, we get:


Total Samples	Running Time	Self (ms)		Symbol Name
1342	134.2ms    5.9%	0.0	 	                                                     0x401e30336a9
1342	134.2ms    5.9%	16.3	 	                                                      blink::WebGLRenderingContextV8Internal::drawElementsMethodCallback(v8::FunctionCallbackInfo<v8::Value> const&)
1157	115.7ms    5.1%	33.4	 	                                                       blink::WebGLRenderingContextBase::drawElements(unsigned int, int, unsigned int, long long)
458	45.8ms    2.0%	14.5	 	                                                        blink::PaintLayer::contentChanged(blink::ContentChangeType)
273	27.3ms    1.2%	5.0	 	                                                         blink::GraphicsLayer::setContentsNeedsDisplay()
223	22.3ms    0.9%	3.7	 	                                                          cc_blink::WebLayerImpl::invalidate()
178	17.8ms    0.7%	17.8	 	                                                           cc::Layer::SetNeedsDisplayRect(gfx::Rect const&)
 

Is this a WontFix?

If the overhead's insignificant then yes -- but we really need to fix  Issue 608873  before we can know whether this is actually expensive.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

ccameron@ simplified this logic in http://crrev.com/511693 and I doubt that this is a bottleneck at this point.

Duplicating this into the bug that that CL intended to reference, per http://crrev.com/510901 .