Last Comment Bug 739671 - Order of ColorLayers is reversed every paint
: Order of ColorLayers is reversed every paint
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla17
Assigned To: Matt Woodrow (:mattwoodrow)
:
Mentors:
Depends on:
Blocks: dlbi
  Show dependency treegraph
 
Reported: 2012-03-27 09:40 PDT by Matt Woodrow (:mattwoodrow)
Modified: 2012-08-21 06:33 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Reverse ImageLayer ordering (1.77 KB, patch)
2012-03-27 09:40 PDT, Matt Woodrow (:mattwoodrow)
roc: review+
Details | Diff | Review
Attach ImageLayers to the ThebesLayer it replaces (9.36 KB, patch)
2012-04-25 20:40 PDT, Matt Woodrow (:mattwoodrow)
roc: review+
Details | Diff | Review

Description Matt Woodrow (:mattwoodrow) 2012-03-27 09:40:15 PDT
Created attachment 609753 [details] [diff] [review]
Reverse ImageLayer ordering

When we have multiple ColorLayers within a single container, their order is reversed every paint.

I believe this is because we process ThebesLayers in a stack, so we should be retrieving the ColorLayers (and ImageLayers) in reverse order.
Comment 1 Matt Woodrow (:mattwoodrow) 2012-04-25 20:40:46 PDT
Created attachment 618538 [details] [diff] [review]
Attach ImageLayers to the ThebesLayer it replaces

Turns out that the original approach didn't actually work. The ordering isn't consistent at all, and reversing the order broke as many tests as it fixed.
Comment 2 Matt Woodrow (:mattwoodrow) 2012-04-25 20:41:08 PDT
CC'ing nrc since this may affect his MaskLayer patches
Comment 3 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-04-25 20:50:45 PDT
Comment on attachment 618538 [details] [diff] [review]
Attach ImageLayers to the ThebesLayer it replaces

Review of attachment 618538 [details] [diff] [review]:
-----------------------------------------------------------------

Good plan
Comment 4 Matt Woodrow (:mattwoodrow) 2012-06-10 21:50:54 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/d80219c8842c
Comment 5 Ed Morley [:emorley] 2012-06-11 02:21:14 PDT
Ok, so this is pretty sad faces, but I've had to back this out for causing mochitest-4 permaorange (as well as the talos regressions in comment 237):
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=61fd66629c4f

eg https://tbpl.mozilla.org/php/getParsedLog.php?id=12544443&tree=Mozilla-Inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/f08886a8cf22

It's for times like these that a relanding script would be pretty useful, for automating the qimport of a lange range of changesets (or at least it would make me feel less bad about having to back things like this out). 

Sorry! :-(
Comment 6 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-06-18 23:10:54 PDT
I presume comment #5 was for bug 539356.
Comment 7 Matt Woodrow (:mattwoodrow) 2012-06-29 20:17:12 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/90ab708bab8b
Comment 8 Ryan VanderMeulen [:RyanVM] 2012-06-30 12:42:35 PDT
https://hg.mozilla.org/mozilla-central/rev/90ab708bab8b
Comment 9 Matt Woodrow (:mattwoodrow) 2012-08-20 03:02:47 PDT
This got backed out with the rest of 539356 initially.

https://hg.mozilla.org/integration/mozilla-inbound/rev/bc76f965c041
Comment 10 Ed Morley [:emorley] 2012-08-21 06:33:22 PDT
https://hg.mozilla.org/mozilla-central/rev/bc76f965c041

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