Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

content doesn't fill fast enough when you resize a browser window horizontally #586

Closed
asadotzler opened this issue Feb 3, 2016 · 21 comments · Fixed by #5102
Closed

content doesn't fill fast enough when you resize a browser window horizontally #586

asadotzler opened this issue Feb 3, 2016 · 21 comments · Fixed by #5102
Labels
bug fixed-with-brave-core This issue will automatically resolved with the replacement of Muon with Brave Core. initiative/perf perf priority/P5 Cosmetic. Spelling, copy, layout. New features (which should also be part of an initiative). wontfix

Comments

@asadotzler
Copy link

Load a site like slashdot.org. Not too complex. Resize the window horizontally and notice the content doesn't fill in very quickly. It's very easy on Mac and Windows, even on relatively new equipment, to outrace the content leaving a blank area before the content races to catch up with the window edge. It feels very janky, laggy, bad. Video attached.

refill.mov.zip

also on youtube https://youtu.be/gnE1--66q-I

@asadotzler asadotzler changed the title content doesn't repaint fast enough when you resize a browser window horizontally content doesn't fill fast enough when you resize a browser window horizontally Feb 3, 2016
@bbondy
Copy link
Member

bbondy commented Feb 5, 2016

Just noting for now, a big part of this is that there's an app state change that happens on resize here js/stores/appStore.js:

  mainWindow.on('resize', function (evt) {
    // the default window size is whatever the last window resize was
    AppActions.setDefaultWindowSize(evt.sender.getSize())
  })

That triggers the app state to be communicated to the window over IPC. We should look to minimize app state transfer for things that only matter to the app itself, like the default window position size.

@bbondy bbondy modified the milestone: 0.7Next Feb 5, 2016
@bbondy
Copy link
Member

bbondy commented Feb 10, 2016

Several UI snappy fixes in 0.7.14.
This is improved with 0.7.14 but not good enough to close this yet.

@poiru
Copy link

poiru commented Aug 22, 2016

Much of this is due to <webview> being slow to resize. See https://bugs.chromium.org/p/chromium/issues/detail?id=639867

@bbondy @bridiver Have you considered patching libchromiumcontent to fix or work around this?

@bridiver
Copy link
Collaborator

right now it's low on the priority list, but at some point after 1.0 we'll take a closer look. I dug through the code a little bit and it's certainly not a trivial fix

@luixxiul luixxiul added this to the 1.1.0 milestone Oct 15, 2016
@bsclifton bsclifton modified the milestones: 0.12.7dev, 1.1.0 Oct 24, 2016
@bsclifton bsclifton self-assigned this Oct 24, 2016
@poiru
Copy link

poiru commented Oct 25, 2016

FYI, resizing performance for webviews can be improved quite a bit with electron/electron#7658 (cc @bridiver, @bsclifton).

@bridiver
Copy link
Collaborator

I'll take a look. Thanks!

@bridiver
Copy link
Collaborator

lgtm! I'll cherry-pick it when I'm done with the chromium 54 update

@bsclifton
Copy link
Member

@bridiver nice 😄 I created brave/muon#78 for ya

If you get a sec, check out the fix I did event-wise in #5102

@bridiver
Copy link
Collaborator

was #5102 supposed to close this?

@bsclifton
Copy link
Member

@bridiver yes- the performance is noticeably better 😄

@bridiver
Copy link
Collaborator

ok, but I assume we still want to pull in the upstream change?

@bsclifton
Copy link
Member

@bridiver yup! and that is captured with brave/muon#78

@bbondy bbondy reopened this Oct 27, 2016
@bbondy bbondy removed this from the 0.12.7dev milestone Oct 27, 2016
@bbondy
Copy link
Member

bbondy commented Oct 27, 2016

Sorry this was mistakenly closed, it's more about content not filling in the resizing window fast enough.

@bsclifton
Copy link
Member

bsclifton commented Dec 19, 2016

With brave/muon#78 closed, we should retest this starting with 0.13.0 😄

If it's not fixed, let's remove the milestone and leave some notes here

@bsclifton bsclifton added this to the 0.13.0 milestone Dec 19, 2016
@bridiver
Copy link
Collaborator

it was closed because the patch no longer applied, but I have no idea if the behavior has changed or not

@bsclifton
Copy link
Member

Gave it a go, performance didn't seem any better. Was worth a shot 😄 Removing milestone

@bsclifton bsclifton removed this from the 0.13.0 milestone Dec 20, 2016
@bsclifton bsclifton removed their assignment Dec 20, 2016
@bridiver
Copy link
Collaborator

a similar change may or may not work for the chromium webview

@bradleyrichter
Copy link
Contributor

This was getting better through 0.12.5 and now became worse again with 0.13.0 based on my personal mac OS experience.

@bridiver
Copy link
Collaborator

@bradleyrichter in 0.13 we switched from the electron webview to the chrome webview and that may have had an impact because the resizing code is different

@bsclifton bsclifton added perf priority/P5 Cosmetic. Spelling, copy, layout. New features (which should also be part of an initiative). initiative/perf and removed priority/low (deprecated) labels Nov 22, 2017
@bsclifton bsclifton added this to the Backlog (Prioritized) milestone Nov 22, 2017
@bsclifton bsclifton added the fixed-with-brave-core This issue will automatically resolved with the replacement of Muon with Brave Core. label Jul 25, 2018
@bsclifton bsclifton removed this from the Backlog (Prioritized) milestone Jul 25, 2018
@bsclifton
Copy link
Member

This issue will be solved when we move to the Chromium UI (Brave Core)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug fixed-with-brave-core This issue will automatically resolved with the replacement of Muon with Brave Core. initiative/perf perf priority/P5 Cosmetic. Spelling, copy, layout. New features (which should also be part of an initiative). wontfix
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants