Closed
Bug 1064478
Opened 10 years ago
Closed 4 years ago
Call glFlush() of WebGL and SkiaGL at correct timing
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: sotaro, Unassigned)
References
Details
+++ This bug was initially created as a clone of Bug #1049195 +++
This bug is created based on Bug 1049195 Comment 107.
Bug 1049195 fixes the problem by calling glFlush, if glFlush() is not called during LayerTransaction. But it is not ideal way to solve the problem.
In current gecko, Call glFlush() is triggered by LayerTransaciton. In SkiaGL case, it is called like the following.
ClientCanvasLayer::RenderLayer()
->CanvasClientSurfaceStream::Update()
->SurfaceStream_TripleBuffer::SwapProducer()
->SharedSurface_Gralloc::Fence()
->glFlush()
canvas's drawing could happen even when CanvasLayer does not exit, but glFlush()call is dependent LayerTransaciton. It is ideal, we could handle glFlush() independently if CanvasLayer exists. And call glFlush() before LayerTransaction. It is good also from performance point of view.
Reporter | ||
Updated•10 years ago
|
Summary: Call glFlush() of WebGL and SkiaGL in correct timing → Call glFlush() of WebGL and SkiaGL an correct timing
Reporter | ||
Updated•10 years ago
|
Summary: Call glFlush() of WebGL and SkiaGL an correct timing → Call glFlush() of WebGL and SkiaGL at correct timing
Reporter | ||
Comment 1•10 years ago
|
||
Nominate to b2g-v2.2. bug 1049195 is short term fix and only for b2g-v2.0 and b2g-v2.1.
blocking-b2g: --- → 2.2?
Reporter | ||
Comment 2•10 years ago
|
||
Clear the blocking request based on Bug 1049195 comment 116.
blocking-b2g: 2.2? → ---
Updated•4 years ago
|
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•