736863 - gl.clear extremely slow on CubicVR.js-using page

Status: RESOLVED INCOMPLETE

(Core :: Graphics: CanvasWebGL, defect)

Description

[Alon Zakai (:azakai)]

Attachment: testcase

I bisected the original benchmark that led to the testcase in bug 736784 in a different way and found this. Not sure if the two are related or not - they seem different but maybe there is a common underlying problem.

STR:

1. Unzip the attachment with the testcase
2. Open the html file in Firefox
3. When the page is in the foreground, CPU usage is very high. I get 70% for Firefox and 40% for Xorg.

However, the page does basically nothing but gl.clear(). It runs a main loop using requestAnimationFrame, inside of which all we do is gl.clear(). If you comment out the gl.clear() call in CubicVR.js line 7108 (inside loopFunc), the high CPU usage will vanish (and it will be like Chrome's behavior on this testcase - use almost 0% CPU).

I tried oprofile on this, but the data looks spurious: A combination of JS GC (js::GCMarker::drainMarkStack, js::gc::FinalizeArenas), malloc/free, and below them some of the same functions that looked suspicious in bug bug 736784.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So profiling this on Mac, I see the following:

  52% under painting some of this is cocoa/corefoundation/etc overhead, but about half is
      under LayerManagerOGL::Render
  10% under the refresh timer, of which about 6% is the actual clear() call (half is
      invalidation, and half is glClear_Exec).

The rest is various event loop overhead, GC, and so forth, as far as I can see).

The upshot is we end up repainting at least the canvas on each clear() call, I think.  We could clearly optimize away clear() on a already-cleared canvas, but it's not obvious to me that this is worthwhile...  What happens if in between the clear() calls a single line is drawn to the canvas?

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

We already try to optimize away gl.clear() on a already-cleared canvas, in particular we have all the infrastructure for doing so, but we could of course have a bug. See WebGLContext::Clear in WebGLContext.cpp.

Comment 3

[Alon Zakai (:azakai)]

Why does repainting the canvas take so much CPU, though? It seems like even if we do paint it 60 times a second, it should be very cheap.

Comment 4

[Kelsey Gilbert [:jgilbert]]

This is probably just our lack of HW accel compositing on Linux.