Open
Bug 1374710
Opened 7 years ago
Updated 2 years ago
GLBlitHelper should cache the various shaders
Categories
(Core :: Graphics, enhancement, P5)
Core
Graphics
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox57 | --- | fix-optional |
People
(Reporter: jya, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: feature, Whiteboard: [gfx-noted])
Whenever GLBlitHelper::BlitImageToFramebuffer is called, it will call GLBlitHelper::InitTexQuadProgram.
This code will compile the various shaders required for the conversion.
This is done every single time BlitImageToFramebuffer is called.
I haven't profiled that code, however, it's not hard to imagine that the shaders compilation take a significant amount of time...
This work should be cached and reuse when/if possible.
Reporter | ||
Comment 1•7 years ago
|
||
Actually, running a profiler on https://people-mozilla.org/~jyavenard/webgl-videotest/webgl-videotest.html?fast=true (after disabling the HW decoder) as FastPath only works with YUV software images. and e10s off
The majority of time is spent in:
Function Name Total CPU (%) Self CPU (%) Total CPU (ms) Self CPU (ms) Module
+ nsDisplayList::PaintRoot 16.90 % 0.00 % 1533 0 xul.dll
Only 5% in:
Function Name Total CPU (%) Self CPU (%) Total CPU (ms) Self CPU (ms) Module
+ mozilla::dom::WebGLRenderingContextBinding::texImage2D 5.09 % 0.00 % 462 0 xul.dll
of that, it's almost exclusively mozilla::gl::GLBlitHelper::BlitImageToFramebuffer 4.85 %
InitTexQuadProgram is only 0.02%
So this bug is likely irrelevant in the grand scheme of things.
Updated•7 years ago
|
Updated•7 years ago
|
Whiteboard: [gfx-noted]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•