Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Disable compositor recycling only for attached views #20829

Merged

Conversation

poiru
Copy link
Contributor

@poiru poiru commented Oct 29, 2019

In #19873, we completely disabled compositor recycling. This has adverse
effects in our tabbed app where switching tabs (i.e. BrowserViews) now
results in a flicker because we now also switch compositors.

To fix this without regressing the original fix, we now recycle the
compositor when the view is removed from a window or explicitly marked
as hidden. These can only happen with BrowserViews so BrowserWindows
are unaffected.

Notes: Fix flicker when switching between BrowserViews

@poiru poiru requested a review from a team as a code owner October 29, 2019 15:48
@electron-cation electron-cation bot added the new-pr 🌱 PR opened in the last 24 hours label Oct 29, 2019
@poiru poiru force-pushed the recycle-compositor-for-removed-views branch 2 times, most recently from afbae72 to 8a67e74 Compare October 29, 2019 18:08
@@ -1,20 +1,25 @@
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Andy Locascio <andy@slack-corp.com>
Date: Wed, 21 Aug 2019 12:09:10 -0700
From: Birunthan Mohanathas <birunthan@mohanathas.com>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you comma separate the authors ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reverted this bit.

@deepak1556
Copy link
Member

/cc @loc

@poiru poiru force-pushed the recycle-compositor-for-removed-views branch from 8a67e74 to 8cd600c Compare October 29, 2019 18:56
poiru added a commit to poiru/electron that referenced this pull request Oct 29, 2019
Backport of electron#20829

Notes: Fix flicker when switching between `BrowserView`s
@trop
Copy link
Contributor

trop bot commented Oct 29, 2019

@poiru has manually backported this PR to "6-1-x", please check out #20834

Copy link
Member

@MarshallOfSound MarshallOfSound left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking this on a manual check the original issue has not resurfaced. We can't afford that that happening.

In electron#19873, we completely disabled compositor recycling. This has adverse
effects in our tabbed app where switching tabs (i.e. `BrowserView`s) now
results in a flicker because we now also switch compositors.

To fix this without regressing the original fix, we now recycle the
compositor when the view is removed from a window. This situation can
only happen with `BrowserView`s and the common case with `BrowserWindow`
is unaffected.
@poiru poiru force-pushed the recycle-compositor-for-removed-views branch from 8cd600c to 05f385a Compare October 30, 2019 00:12
@loc
Copy link
Contributor

loc commented Oct 30, 2019

This regresses the original fix. With the original fix, the RenderWidgetHost is never hidden as far as the compositor is concerned, whereas your patch allows it to be hidden if the NSView is hidden. I think the logic we actually want is more like:

render_widget_host_is_hidden_ = [GetInProcessNSView() window] ? false : hidden;

with hidden being the passed bool.

Edit: Oh I see you just pushed changes. Now it won't regress, but I still think we want to set it to the passed bool for the BrowserView case?
Edit 2: Ah, I was reading the patch wrong. Poiru set me straight in a DM.

@poiru
Copy link
Contributor Author

poiru commented Oct 30, 2019

@loc I actually just fixed that, please refresh the PR 😊

With the updated patch and this logging statement...

 void BrowserCompositorMac::SetRenderWidgetHostIsHidden(bool hidden) {
+  LOG(ERROR) << (hidden ? "COMPOSITOR HIDDEN" : "COMPOSITOR SHOWN");
   render_widget_host_is_hidden_ = hidden;
   UpdateState();
 }

... the results are as follows:

  • Minimizing and restoring window
COMPOSITOR SHOWN
COMPOSITOR SHOWN
  • Occluding and unoccluding window
COMPOSITOR SHOWN
COMPOSITOR SHOWN
  • Removing a BrowserView from a window and adding it back
COMPOSITOR HIDDEN
COMPOSITOR SHOWN

So I think we should be good to go!

poiru added a commit to poiru/electron that referenced this pull request Oct 30, 2019
Backport of electron#20829

Notes: Fix flicker when switching between `BrowserView`s
poiru added a commit to poiru/electron that referenced this pull request Oct 30, 2019
Backport of electron#20829

Notes: Fix flicker when switching between `BrowserView`s
poiru added a commit to poiru/electron that referenced this pull request Oct 30, 2019
Backport of electron#20829

Notes: Fix flicker when switching between `BrowserView`s
@trop
Copy link
Contributor

trop bot commented Oct 30, 2019

@poiru has manually backported this PR to "7-0-x", please check out #20846

@electron-cation electron-cation bot removed the new-pr 🌱 PR opened in the last 24 hours label Oct 30, 2019
Copy link
Contributor

@loc loc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change looks good. I tested that the 6-1-x backport does not regress.

Upon further investigation though, it looks like we had already regressed on the original bug in Electron 7 and 8 — I'll make an issue and investigate further.

Copy link
Member

@MarshallOfSound MarshallOfSound left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for checking it out @loc

@MarshallOfSound MarshallOfSound merged commit b275273 into electron:master Oct 30, 2019
@release-clerk
Copy link

release-clerk bot commented Oct 30, 2019

Release Notes Persisted

Fix flicker when switching between BrowserViews

@poiru poiru deleted the recycle-compositor-for-removed-views branch October 30, 2019 20:50
jkleinsc pushed a commit that referenced this pull request Oct 30, 2019
…0847)

Backport of #20829

Notes: Fix flicker when switching between `BrowserView`s
jkleinsc pushed a commit that referenced this pull request Oct 30, 2019
…0834)

Backport of #20829

Notes: Fix flicker when switching between `BrowserView`s
jkleinsc pushed a commit that referenced this pull request Oct 30, 2019
…0846)

Backport of #20829

Notes: Fix flicker when switching between `BrowserView`s
@sofianguy sofianguy added this to Fixed in 7.0.1 in 7.2.x Nov 4, 2019
@sofianguy sofianguy added this to Fixed in 6.1.3 in 6.1.x Nov 5, 2019
@sofianguy sofianguy added this to Fixed in 8.0.0-beta.2 in 8.2.x Nov 5, 2019
poiru added a commit to poiru/electron that referenced this pull request Dec 3, 2019
In electron#20829, we fixed compositor recycling when switching between
BrowserViews, but it turns out that there is one additional case that we
need to handle. When we create a completely new BrowserView instance, it
starts of as visible (even when it hasn't been added to the window),
which means that it will need its own compositor instead of using the
recycled compositor.

To fix this, lets make BrowserViews hidden by default until they're
added to the window. See also electron#19988. This is a potentially breaking
change given that the initial value of `document.visibilityState` will
now be `hidden`, but given the experimental status of BrowserViews, I
think this is a fine change to make. The old behavior can be restored
with `webPreferences: { show: true }`.

Notes: Fix compositor recycling when creating new BrowserView
poiru added a commit to poiru/electron that referenced this pull request Dec 4, 2019
In electron#20829, we fixed compositor recycling when switching between
BrowserViews, but it turns out that there is one additional case that we
need to handle. When we create a completely new BrowserView instance, it
starts of as visible (even when it hasn't been added to the window),
which means that it will need its own compositor instead of using the
recycled compositor.

To fix this, lets make BrowserViews hidden by default until they're
added to the window. See also electron#19988. This is a potentially breaking
change given that the initial value of `document.visibilityState` will
now be `hidden`, but given the experimental status of BrowserViews, I
think this is a fine change to make. The old behavior can be restored
with `webPreferences: { show: true }`.

Notes: Fix compositor recycling when creating new BrowserView
poiru added a commit to poiru/electron that referenced this pull request Dec 4, 2019
In electron#20829, we fixed compositor recycling when switching between
BrowserViews, but it turns out that there is one additional case that we
need to handle. When we create a completely new BrowserView instance, it
starts of as visible (even when it hasn't been added to the window),
which means that it will need its own compositor instead of using the
recycled compositor.

To fix this, lets make BrowserViews hidden by default until they're
added to the window. See also electron#19988. This is a potentially breaking
change given that the initial value of `document.visibilityState` will
now be `hidden`, but given the experimental status of BrowserViews, I
think this is a fine change to make. The old behavior can be restored
with `webPreferences: { show: true }`.

Notes: Fix compositor recycling when creating new BrowserView
MarshallOfSound pushed a commit that referenced this pull request Dec 5, 2019
In #20829, we fixed compositor recycling when switching between
BrowserViews, but it turns out that there is one additional case that we
need to handle. When we create a completely new BrowserView instance, it
starts of as visible (even when it hasn't been added to the window),
which means that it will need its own compositor instead of using the
recycled compositor.

To fix this, lets make BrowserViews hidden by default until they're
added to the window. See also #19988. This is a potentially breaking
change given that the initial value of `document.visibilityState` will
now be `hidden`, but given the experimental status of BrowserViews, I
think this is a fine change to make. The old behavior can be restored
with `webPreferences: { show: true }`.

Notes: Fix compositor recycling when creating new BrowserView
trop bot pushed a commit that referenced this pull request Dec 5, 2019
In #20829, we fixed compositor recycling when switching between
BrowserViews, but it turns out that there is one additional case that we
need to handle. When we create a completely new BrowserView instance, it
starts of as visible (even when it hasn't been added to the window),
which means that it will need its own compositor instead of using the
recycled compositor.

To fix this, lets make BrowserViews hidden by default until they're
added to the window. See also #19988. This is a potentially breaking
change given that the initial value of `document.visibilityState` will
now be `hidden`, but given the experimental status of BrowserViews, I
think this is a fine change to make. The old behavior can be restored
with `webPreferences: { show: true }`.

Notes: Fix compositor recycling when creating new BrowserView
trop bot pushed a commit that referenced this pull request Dec 5, 2019
In #20829, we fixed compositor recycling when switching between
BrowserViews, but it turns out that there is one additional case that we
need to handle. When we create a completely new BrowserView instance, it
starts of as visible (even when it hasn't been added to the window),
which means that it will need its own compositor instead of using the
recycled compositor.

To fix this, lets make BrowserViews hidden by default until they're
added to the window. See also #19988. This is a potentially breaking
change given that the initial value of `document.visibilityState` will
now be `hidden`, but given the experimental status of BrowserViews, I
think this is a fine change to make. The old behavior can be restored
with `webPreferences: { show: true }`.

Notes: Fix compositor recycling when creating new BrowserView
ckerr pushed a commit that referenced this pull request Dec 5, 2019
In #20829, we fixed compositor recycling when switching between
BrowserViews, but it turns out that there is one additional case that we
need to handle. When we create a completely new BrowserView instance, it
starts of as visible (even when it hasn't been added to the window),
which means that it will need its own compositor instead of using the
recycled compositor.

To fix this, lets make BrowserViews hidden by default until they're
added to the window. See also #19988. This is a potentially breaking
change given that the initial value of `document.visibilityState` will
now be `hidden`, but given the experimental status of BrowserViews, I
think this is a fine change to make. The old behavior can be restored
with `webPreferences: { show: true }`.

Notes: Fix compositor recycling when creating new BrowserView
zcbenz pushed a commit that referenced this pull request Dec 10, 2019
In #20829, we fixed compositor recycling when switching between
BrowserViews, but it turns out that there is one additional case that we
need to handle. When we create a completely new BrowserView instance, it
starts of as visible (even when it hasn't been added to the window),
which means that it will need its own compositor instead of using the
recycled compositor.

To fix this, lets make BrowserViews hidden by default until they're
added to the window. See also #19988. This is a potentially breaking
change given that the initial value of `document.visibilityState` will
now be `hidden`, but given the experimental status of BrowserViews, I
think this is a fine change to make. The old behavior can be restored
with `webPreferences: { show: true }`.

Notes: Fix compositor recycling when creating new BrowserView
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
6.1.x
Fixed in 6.1.3
7.2.x
Fixed in 7.0.1
8.2.x
Fixed in 8.0.0-beta.2
Development

Successfully merging this pull request may close these issues.

None yet

6 participants