Last Comment Bug 770000 - Video control on html5 video repaint too often on Youtube player
: Video control on html5 video repaint too often on Youtube player
: regression
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: Trunk
: All All
-- normal with 2 votes (vote)
: mozilla17
Assigned To: Matt Woodrow (:mattwoodrow)
: Maire Reavy [:mreavy] Please needinfo me
: 770083 (view as bug list)
Depends on: 782980 783791 797167
Blocks: dlbi
  Show dependency treegraph
Reported: 2012-07-01 03:34 PDT by kolubinowicki
Modified: 2012-10-03 07:29 PDT (History)
13 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Repainting issue on Youtube html5 player (86.62 KB, video/webm)
2012-07-01 03:34 PDT, kolubinowicki
no flags Details
Call WillPaint/DidPaint in the right place (6.03 KB, patch)
2012-07-02 21:14 PDT, Matt Woodrow (:mattwoodrow)
roc: review+
Details | Diff | Splinter Review

Description User image kolubinowicki 2012-07-01 03:34:11 PDT
Created attachment 638175 [details]
Repainting issue on Youtube html5 player

Please check attachment for more info:

Video control on html5 video repaint to often on Youtube player:

Step to reproduce:

Enable Html5 video on page:
Open example video:
look at the video controls button:

Regression window:


Comment 1 User image Jim Jeffery not reading bug-mail 1/2/11 2012-07-01 05:50:02 PDT
Confirmed - setting to New
Comment 2 User image Chris Pearce (:cpearce) 2012-07-01 15:52:54 PDT
Smells like a DLBI regression.
Comment 3 User image Kevin Brosnan [:kbrosnan] 2012-07-02 16:33:02 PDT
This happens on all platforms.
Comment 4 User image Matt Woodrow (:mattwoodrow) 2012-07-02 17:38:16 PDT
Initial testing of this shows this for the invalidation log:

This means that the elapsed time text frame was deleted when we painted, and we didn't have the new text frame created (or at least, it didn't create an nsDisplayText display item).

Unsure how this could have changed under DLBI, unless we just weren't invalidating (or painting) previously until the text frame is created.
Comment 5 User image Matt Woodrow (:mattwoodrow) 2012-07-02 21:14:21 PDT
Created attachment 638584 [details] [diff] [review]
Call WillPaint/DidPaint in the right place

Ok, confirmed this to be the latter.

The original text frame is removed, and we invalidate part of the layer. Then we paint on a refresh driver tick, draw with missing text and send an invalidate event to the widget. Then the new text frame is created before the widget paint event fires.

With the old code, we didn't paint until the widget event, so we would have drawn the text.

I think we need to move the code for WillPaint/DidPaint into being called around the refresh driver paint, instead of being called by the OS surrounding the widget paint (composite).

This patch fixes the flicker for me.
Comment 6 User image Matt Woodrow (:mattwoodrow) 2012-07-02 21:18:45 PDT
*** Bug 770083 has been marked as a duplicate of this bug. ***
Comment 7 User image Matt Woodrow (:mattwoodrow) 2012-07-03 02:19:07 PDT
Comment 8 User image Ryan VanderMeulen [:RyanVM] 2012-07-03 16:08:41 PDT
Comment 9 User image :Ehsan Akhgari 2012-07-03 18:00:15 PDT
Backed out as part of DLBI:
Comment 10 User image Matt Woodrow (:mattwoodrow) 2012-08-13 03:14:56 PDT
Comment 11 User image Ed Morley [:emorley] 2012-08-13 11:10:37 PDT

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