Closed Bug 1119742 Opened 5 years ago Closed 5 years ago

Add RefreshTimerDispatcher into VsyncSource::Display

Categories

(Core :: Graphics, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED FIXED
mozilla38
Tracking Status
firefox36 --- wontfix
firefox37 --- wontfix
firefox38 --- fixed
b2g-v2.2 --- fixed
b2g-master --- fixed

People

(Reporter: jerry, Assigned: jerry)

References

Details

Attachments

(2 files, 3 obsolete files)

+++ This bug was initially created as a clone of Bug #1118841 +++

From bug 1092978, Part2: [Silk] Add RefreshTimerDispatcher into VsyncSource::Display. v4, r=kats (https://bugzilla.mozilla.org/attachment.cgi?id=8546520&action=edit), land this patch as this bug.

Successful try - https://treeherder.mozilla.org/#/jobs?repo=try&revision=a58c2380a168
only change the bug number comment.
Attachment #8546531 - Attachment is obsolete: true
please land the attachment 8546533 [details] [diff] [review] to mozilla-central.
Keywords: checkin-needed
Needs rebasing, sorry.
Keywords: checkin-needed
rebase for Bug 1102631 landed
Attachment #8546533 - Attachment is obsolete: true
please land the attachment 8546683 [details] [diff] [review] to mozilla-central.
Keywords: checkin-needed
sorry this does not apply cleanly:

applying Bug-1119742---Add-RefreshTimerDispatcher-into-Vsyn.patch
patching file gfx/thebes/VsyncSource.h
Hunk #1 FAILED at 0
1 out of 1 hunks FAILED -- saving rejects to file gfx/thebes/VsyncSource.h.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
errors during apply, please fix and refresh Bug-1119742---Add-RefreshTimerDispatcher-into-Vsyn.patch

could you take a look ? Thanks!
Flags: needinfo?(hshih)
Flags: needinfo?(hshih)
https://hg.mozilla.org/mozilla-central/rev/bd43663b61a4
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Jerry, please rebase and uplift to Gecko37.
Flags: needinfo?(hshih)
Required as part of silk, bug 987532.
blocking-b2g: --- → 2.2?
No point in requesting blocking since you have to request uplift on the patch anyway; blocking bugs don't get a free uplift. The blocking status is just an extra unnecessary step.
blocking-b2g: 2.2? → ---
Comment on attachment 8548642 [details] [diff] [review]
Add RefreshTimerDispatcher into VsyncSource::Display. for gecko37, r=kats

[Approval Request Comment]
Bug caused by (feature/regressing bug #): none
User impact if declined: a part of silk, bug 987532.
Testing completed:
landed in m-c. m-c try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a58c2380a168
Risk to taking this patch (and alternatives if risky): small
String or UUID changes made by this patch: none
Flags: needinfo?(hshih)
Attachment #8548642 - Flags: approval-mozilla-b2g37?
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #12)
> No point in requesting blocking since you have to request uplift on the
> patch anyway; blocking bugs don't get a free uplift. The blocking status is
> just an extra unnecessary step.

Partially agree atleast for the next 6 weeks. The blocking/feature flag helps us track work that are committed(product, parter, QA ..etc) for the release. 

As an example, if we had a fallout from a non-blocking bug say 8 weeks down the line, then I would backout the bug/feature rather than having discussions on forward fixing etc. But if it was blocking then it indicates it is part of some sort of a must-have feature list for the 2.2 release and I'd rather have more discussions on how to forward fix/QA it. Obviously, it gets down to case-case discussion, but I just wanted to clear the assumption made here :)
Attachment #8548642 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Indeed.  We should be safe requesting (and getting) blocking for any Silk related issues that truly block the Silk meta bug 987532.  I'd say this is one of those.
Makes sense, thanks for the clarification. Restoring flag then.
blocking-b2g: --- → 2.2?
blocking-b2g: 2.2? → ---
You need to log in before you can comment on or make changes to this bug.