Changing the opacity of a div repaints the whole parent

RESOLVED WONTFIX

Status

P1
normal
RESOLVED WONTFIX
6 years ago
6 months ago

People

(Reporter: etienne, Unassigned)

Tracking

unspecified
All
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-basecamp:-)

Details

Attachments

(4 attachments)

(Reporter)

Description

6 years ago
Created attachment 657881 [details]
Test case

The test case will probably be a lot clearer.

It's a big square containing 9 small squares.

If you change the opacity of a "small square" the whole "container square" is repainted.
If you remove the opacity change only the "small square" is repainted.

Note: this is reproducible on a b2g desktop build and on an otoro device but not in Firefox Nightly.
Created attachment 658386 [details] [diff] [review]
Test as patch to gaia template app

Here are the steps I followed to test this
 (1) Apply this patch to gaia, reinstall
 (2) Enable paint flashing
 (3) Open template app
 (4) Tap "small squares"

I only see the small squares being invalidated and repainted.  Is there something else that needs to be done to reproduce this?
(Reporter)

Comment 2

6 years ago
Created attachment 658414 [details] [diff] [review]
Test as patch to gaia UI Tests app

Not sure exactly why yet, it's reproducible in the UI Tests app but not in the template app.

Here is a working gaia patch to reproduce the bug.

STR:
 (1) Apply this patch to gaia, reinstall
 (2) Enable paint flashing
 (3) Open UI Tests app
 (4) Choose the Repain entry (first in the list)
 (4) Tap "small squares"
DLBI does *not* fix this bug.
This hurts pretty bad our e.me integration. blocking-basecamp?
blocking-basecamp: --- → ?
AFAIK e.me integration is a v1 P1 so blocker.
blocking-basecamp: ? → +

Comment 6

6 years ago
Can we turn this into a regular page? That would probably help getting traction for this.
Created attachment 664482 [details]
testcase with transform

If I take Etienne's testcase and wrap it in a CSS transform, I think I see the same problem he reported --- everything updates the entire grid.

However, I think we should land DLBI before tackling this.

Comment 8

6 years ago
When is DLBI going to land? We have a large volume of B2G performance blockers blocked on DLBI. If its not landing within the next days, we are in serious trouble.

Comment 9

6 years ago
I am hearing from JP that DLBI will not make it. We will need a solution without it (I am ok with a hack).

Comment 10

6 years ago
(and the hack can be in the platform or in Gaia)
That is highly distressing.

Comment 12

6 years ago
DLBI landing will be attempted this week. Cross your fingers.
Jonathan, assigning to you to keep an eye on as DLBI comes in.
Assignee: nobody → jwatt

Updated

6 years ago
Priority: -- → P1
Clicking on an element in the grid makes it 'active', and thus forces the nsDisplayTransform into an active layer. This repaints the entire grid.

We then transition back into inactivity, and repaint the grid a second time.

:(
We can use the 3D transform hack to make the grid transform active, to work around this bug, right?
Sure.

Making the transform "transform:scale(1.5) perspective(1px);" fixes the issue.
I'm not sure what else we can do.
I'm not sure what 'active' in the css actually means, or why it's forcing the transform to become an active layer, but we could disable that too.
The CSS :active state just means you're clicking on the element. Unfortunate coincidence of terminology.

It's making the transform active because the change to 'opacity' puts the clicked element in an active layer, so the transform has to be active too.
(In reply to Matt Woodrow (:mattwoodrow) from comment #16)
> Making the transform "transform:scale(1.5) perspective(1px);" fixes the
> issue.

If this workaround does the trick, should we assign this bug to a Gaia hacker who can make the CSS change.
Assignee: jwatt → nobody
Etienne / Vivien, where in e.me should we be looking for bad perf caused by this bug?
blocking-basecamp: + → ?
Flags: needinfo?(etienne)
(In reply to Chris Jones [:cjones] [:warhammer] from comment #21)
> Etienne / Vivien, where in e.me should we be looking for bad perf caused by
> this bug?

Steps to reproduce: 
 - Connect your device with Wifi or 3g
 - Go to the e.me page on the left side of the homescreen
 - Click on the 'Games' category
 - Observe a new list of games icons loading...
 - Once they are loaded, pan the content from the top to the bottom, the opacity should change.
Hm, I'm not sure I'm reproducing the right bad behavior from those STR.  We seem to be doing a pretty job of invalidation.  Would it be possible to make a video?
Gaia workaround = not a blocker.  Re-nom if that's incorrect.
blocking-basecamp: ? → -
(In reply to Chris Jones [:cjones] [:warhammer] from comment #23)
> Hm, I'm not sure I'm reproducing the right bad behavior from those STR.  We
> seem to be doing a pretty job of invalidation.  Would it be possible to make
> a video?

Hum. My build was from last friday and it was pretty obvious, there was repaints on every move. I rebuild today and it seems to be only one repaint.
Flags: needinfo?(etienne)

Comment 26

6 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.