Last Comment Bug 869331 - [B2G/SkiaGL] Flickering with mozillaball
: [B2G/SkiaGL] Flickering with mozillaball
Product: Core
Classification: Components
Component: Canvas: 2D (show other bugs)
: 23 Branch
: ARM Gonk (Firefox OS)
: -- normal (vote)
: mozilla24
Assigned To: Chiajung Hung [:chiajung]
: Milan Sreckovic [:milan]
Depends on:
Blocks: 858237
  Show dependency treegraph
Reported: 2013-05-07 00:43 PDT by Peter Chang[:pchang]
Modified: 2013-05-14 07:54 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

workaround patch (6.00 KB, patch)
2013-05-07 23:28 PDT, Chiajung Hung [:chiajung]
no flags Details | Diff | Splinter Review
workaround patch v2 (5.41 KB, patch)
2013-05-09 02:22 PDT, Chiajung Hung [:chiajung]
no flags Details | Diff | Splinter Review
Patch v1 (995 bytes, patch)
2013-05-13 09:44 PDT, Chiajung Hung [:chiajung]
gwright: review+
Details | Diff | Splinter Review
Patch v1 (1.04 KB, patch)
2013-05-13 14:51 PDT, Chiajung Hung [:chiajung]
ffantasy1999: review+
Details | Diff | Splinter Review

Description Peter Chang[:pchang] 2013-05-07 00:43:06 PDT
With B2G/SkiaGL, saw Red ball flicker in mozillaball app
Comment 1 Peter Chang[:pchang] 2013-05-07 01:54:37 PDT
Based on bug 843599, it still had flicker by adding fence/waitsync implementation.
Comment 2 Peter Chang[:pchang] 2013-05-07 05:45:50 PDT
Mozillaball app used arc/fill to draw the red ball, as shown below.

// Draws a circle of radius 20 at the coordinates 100,100 on the canvas                             

And this problem could be solved by calling DrawTargetSkia::Flush() at the end of draw cmds.

Checking the timing of Flush() calls.
Comment 3 Chiajung Hung [:chiajung] 2013-05-07 23:28:41 PDT
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.
Comment 4 Chiajung Hung [:chiajung] 2013-05-07 23:39:34 PDT
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.
Comment 5 Chiajung Hung [:chiajung] 2013-05-09 02:22:29 PDT
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.
Comment 6 Chiajung Hung [:chiajung] 2013-05-13 09:44:31 PDT
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.
Comment 7 George Wright (:gw280) (:gwright) 2013-05-13 10:24:01 PDT
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.
Comment 8 Chiajung Hung [:chiajung] 2013-05-13 14:48:19 PDT
Comment 9 Chiajung Hung [:chiajung] 2013-05-13 14:51:58 PDT
Created attachment 749018 [details] [diff] [review]
Patch v1

Commitable version, carry r+.
Comment 10 Ryan VanderMeulen [:RyanVM] 2013-05-14 05:35:55 PDT
Comment 11 Ryan VanderMeulen [:RyanVM] 2013-05-14 07:54:11 PDT

Note You need to log in before you can comment on or make changes to this bug.