Closed
Bug 869331
Opened 11 years ago
Closed 11 years ago
[B2G/SkiaGL] Flickering with mozillaball
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
RESOLVED
FIXED
mozilla24
People
(Reporter: pchang, Assigned: chiajung)
References
Details
Attachments
(1 file, 3 obsolete files)
1.04 KB,
patch
|
chiajung
:
review+
|
Details | Diff | Splinter Review |
With B2G/SkiaGL, saw Red ball flicker in mozillaball app https://github.com/mozilla/openwebapps/tree/develop/examples/mozillaball
Reporter | ||
Updated•11 years ago
|
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Reporter | ||
Comment 1•11 years ago
|
||
Based on bug 843599, it still had flicker by adding fence/waitsync implementation.
Reporter | ||
Comment 2•11 years ago
|
||
Mozillaball app used arc/fill to draw the red ball, as shown below. context.clearRect(0,0,320,440); context.beginPath(); context.fillStyle="#0000ff"; // Draws a circle of radius 20 at the coordinates 100,100 on the canvas context.arc(x,y,20,0,Math.PI*2,true); context.closePath(); context.fill(); And this problem could be solved by calling DrawTargetSkia::Flush() at the end of draw cmds. Checking the timing of Flush() calls.
Assignee | ||
Comment 3•11 years ago
|
||
It seems there are 2 problems: 1. SkCanvas do not flushed correctly 2. Rendered data not read out correctly Apply this workaround patch then the ball runs without problem.
Assignee | ||
Comment 4•11 years ago
|
||
I am curious why the gfxSurface contain part render result now. That maybe the key for various similar problem. For this case, you can call mGLContext->PublishFrame before RequestFrame rather than mark out code to fix it, too.
Assignee | ||
Comment 5•11 years ago
|
||
Better fix to the bug. As SkiaGL may queue the draw call until flush, we must flush it before trying to access buffer data.
Attachment #746787 -
Attachment is obsolete: true
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → chung
Assignee | ||
Comment 6•11 years ago
|
||
SkiaGL default to store draw operations in a queue until flush. Flush the queue right before present the frame.
Attachment #747330 -
Attachment is obsolete: true
Attachment #748897 -
Flags: review?(gwright)
Comment 7•11 years ago
|
||
Comment on attachment 748897 [details] [diff] [review] Patch v1 Review of attachment 748897 [details] [diff] [review]: ----------------------------------------------------------------- You probably don't need to check explicitly against nullptr, but this looks good.
Attachment #748897 -
Flags: review?(gwright) → review+
Assignee | ||
Comment 8•11 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=f95e177e1dd0
Assignee | ||
Comment 9•11 years ago
|
||
Commitable version, carry r+.
Attachment #748897 -
Attachment is obsolete: true
Attachment #749018 -
Flags: review+
Assignee | ||
Updated•11 years ago
|
Keywords: checkin-needed
Comment 10•11 years ago
|
||
https://hg.mozilla.org/projects/birch/rev/31c555ae96f3
Keywords: checkin-needed
Comment 11•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/31c555ae96f3
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in
before you can comment on or make changes to this bug.
Description
•