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
fix: Disable compositor recycling only for attached views #20829
Conversation
afbae72
to
8a67e74
Compare
@@ -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> |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reverted this bit.
/cc @loc |
8a67e74
to
8cd600c
Compare
Backport of electron#20829 Notes: Fix flicker when switching between `BrowserView`s
There was a problem hiding this 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.
8cd600c
to
05f385a
Compare
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:
with 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? |
@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:
So I think we should be good to go! |
Backport of electron#20829 Notes: Fix flicker when switching between `BrowserView`s
Backport of electron#20829 Notes: Fix flicker when switching between `BrowserView`s
Backport of electron#20829 Notes: Fix flicker when switching between `BrowserView`s
There was a problem hiding this 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.
There was a problem hiding this 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
Release Notes Persisted
|
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
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
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
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
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
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
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
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
In #19873, we completely disabled compositor recycling. This has adverse
effects in our tabbed app where switching tabs (i.e.
BrowserView
s) nowresults 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
BrowserView
s soBrowserWindow
sare unaffected.
Notes: Fix flicker when switching between
BrowserView
s