The default bug view has changed. See this FAQ.

[B2G/SkiaGL] Flickering with mozillaball

RESOLVED FIXED in mozilla24

Status

()

Core
Canvas: 2D
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: pchang, Assigned: chiajung)

Tracking

23 Branch
mozilla24
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

4 years ago
With B2G/SkiaGL, saw Red ball flicker in mozillaball app

https://github.com/mozilla/openwebapps/tree/develop/examples/mozillaball
(Reporter)

Updated

4 years ago
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
(Reporter)

Comment 1

4 years ago
Based on bug 843599, it still had flicker by adding fence/waitsync implementation.
(Reporter)

Comment 2

4 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.
Blocks: 858237
(Assignee)

Comment 3

4 years ago
Created attachment 746787 [details] [diff] [review]
workaround patch

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

4 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

4 years ago
Created attachment 747330 [details] [diff] [review]
workaround patch v2

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

4 years ago
Assignee: nobody → chung
(Assignee)

Comment 6

4 years ago
Created attachment 748897 [details] [diff] [review]
Patch v1

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 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

4 years ago
https://tbpl.mozilla.org/?tree=Try&rev=f95e177e1dd0
(Assignee)

Comment 9

4 years ago
Created attachment 749018 [details] [diff] [review]
Patch v1

Commitable version, carry r+.
Attachment #748897 - Attachment is obsolete: true
Attachment #749018 - Flags: review+
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
https://hg.mozilla.org/projects/birch/rev/31c555ae96f3
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/31c555ae96f3
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.