Closed
Bug 770000
Opened 12 years ago
Closed 12 years ago
Video control on html5 video repaint too often on Youtube player
Categories
(Core :: Audio/Video, defect)
Core
Audio/Video
Tracking
()
RESOLVED
FIXED
mozilla17
People
(Reporter: kolubinowicki, Assigned: mattwoodrow)
References
Details
(Keywords: regression)
Attachments
(2 files)
86.62 KB,
video/webm
|
Details | |
6.03 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
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: http://www.youtube.com/html5 Open example video: http://www.youtube.com/watch?v=mzPxo7Y6JyA look at the video controls button: Regression window: OK: http://hg.mozilla.org/mozilla-central/rev/f08d285b63b0 BAD: http://hg.mozilla.org/mozilla-central/rev/d9d61d199b11
Reporter | ||
Updated•12 years ago
|
Blocks: dlbi
Keywords: regression
Updated•12 years ago
|
Attachment #638175 -
Attachment mime type: application/octet-stream → video/webm
Comment 2•12 years ago
|
||
Smells like a DLBI regression.
Summary: Video control on html5 video repaint to often on Youtube player → Video control on html5 video repaint too often on Youtube player
Assignee | ||
Comment 4•12 years ago
|
||
Initial testing of this shows this for the invalidation log: http://pastebin.mozilla.org/1688404 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.
Assignee | ||
Comment 5•12 years ago
|
||
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.
Attachment #638584 -
Flags: review?(roc)
Attachment #638584 -
Flags: review?(roc) → review+
Assignee | ||
Comment 7•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/674cde7d007a
Comment 8•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/674cde7d007a
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
Comment 9•12 years ago
|
||
Backed out as part of DLBI: https://hg.mozilla.org/mozilla-central/rev/674cde7d007a
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 10•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/0ad204385022
Status: REOPENED → NEW
Target Milestone: mozilla16 → ---
Comment 11•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/0ad204385022
Status: NEW → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Updated•12 years ago
|
Assignee: nobody → matt.woodrow
You need to log in
before you can comment on or make changes to this bug.
Description
•