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

Lots of Physical Items generated/No Way to Cap Physical Items #506

Open
ggriffithsIDBS opened this issue Feb 5, 2018 · 9 comments
Open

Comments

@ggriffithsIDBS
Copy link

ggriffithsIDBS commented Feb 5, 2018

Expected outcome

When i am rendering complex items e.g. a Web Components with slots etc, i expect to be able to do this efficiently with a virtual list - iron-list.

In the version 1.X stream of the branch you can set: max-physical-count to control this.

Actual outcome

Instead i find what happens with the more recent versions any since (1.3.15), i find that iron-list seems to uncontrollably create elements, which leads to the browser locking up.

the code now appears to constantly call "_increasePoolIfNeeded" when you are scrolling fast which leads to mass generation of DOM nodes and browser locking up.
I've tried to follow the logic in _increasePoolIfNeeded but its rather messy

Browsers Affected

  • [ x] Chrome

Polymer Versions

1.x and 2.X

collapse-demo

Demo above uses the "collapse" demo from the iron-overlay repository, you can see at some point durin the scrolling the code decide to generate lots of nodes at once, for large lists/complex components this causes heavy browser lag.

Can reproduce with:
https://raw-dot-custom-elements.appspot.com/PolymerElements/iron-list/v2.0.12/iron-list/demo/collapse.html

The more content you have to worse this issue appears to be

@ggriffithsIDBS
Copy link
Author

Gif should show the issue, in the gif i am scrolling my list down and suddenly it start rendering up to maximum of the list :S

iron-list

@ggriffithsIDBS ggriffithsIDBS changed the title No Way to Cap Physical Items Lots of Physical Items generated/No Way to Cap Physical Items Feb 6, 2018
@mario-aleo
Copy link

I'm having the same issue when i use the scroll method to go back to the top of the list :(

@moodyjmz
Copy link

moodyjmz commented Jun 28, 2018

Is iron list getting a specific height? I was having a similar issue and this seems to be the cause for me. Now to get it working properly in FF and IE where the scroll seems completely broken

@ggriffithsIDBS
Copy link
Author

@moodyjmz That appeared to be the issue, thanks :) 👍

@mtbradle-ge
Copy link

Any update on this? I still see this issue while setting a height explicitly. Version 2.0.19.

@RuslanKim
Copy link

I see the same issue with iron-list 3.0.2, specially when item has input fields like paper-input...
Is there a way to limit 'physical' items count?

@moodyjmz
Copy link

The height can't be %.

I don't know of a way to limit physical items.

I think the issue of flooding the physical items pool arises as the delta is calculated and _increasePoolIfNeeded debounces itself recursively and asynchronously as a microTask or during the idlePeriod. Basically it will keep running and call itself.

If you are able to to use [iron-list].updateViewportBoundaries(); you may be able to mitigate it.

Or extend iron-list and modify _increasePoolIfNeeded to do:

  _increasePoolIfNeeded(count) {
    this.updateViewportBoundaries();
    super._increasePoolIfNeeded(count);
  }

Forcing height related values to be updated, it may help.

If you are applying dynamic heights to the list - ie changing numbers of items, you'd need a more involved approach.

iron-list has significant holes in it and my suggestions are mere plugs in those holes.

@RuslanKim
Copy link

It does not help for me... I've tried increase denounce period from microTask to timeout.after - 150ms and tried to use 'updateViewportBoundaries' as well it does not help...
I just scroll down on the reloaded page it uses 40 physical items (DOM elements) for 800 virtual items... but when I'm starting to scroll up - something goes wrong and it starts to create 800 physical items for 800 virtual (equally). As far as each item too heavy ...page becomes unusable ... :(

@RuslanKim
Copy link

I have added a property:
defaultPhysicalCount: { type: Number, value: DEFAULT_PHYSICAL_COUNT },

and the logic is - when element has defined outside a value - it means suppress an auto increasing physical elements...and it helps me for now, at least we have approximately limited height of screens
:)

use everywhere the property this.defaultPhysicalCount vs const DEFAULT_PHYSICAL_COUNT

here is a part of code _increasePoolIfNeeded

`var autoIncrease = this.defaultPhysicalCount == DEFAULT_PHYSICAL_COUNT

// The upper bounds is not fixed when dealing with a grid that doesn't
// fill it's last row with the exact number of items per row.
if (this._virtualEnd >= this._virtualCount - 1 || nextIncrease === 0) {
  // Do nothing.
} else if (!this._isClientFull() && **autoIncrease**) {
  this._debounce(
      '_increasePoolIfNeeded',
      this._increasePoolIfNeeded.bind(this, nextIncrease),
      microTask);
} else if (this._physicalSize < this._optPhysicalSize && **autoIncrease**) {
  // Yield and increase the pool during idle time until the physical size is
  // optimal.
  this._debounce(
      '_increasePoolIfNeeded',
      this._increasePoolIfNeeded.bind(
          this,
          this._clamp(
              Math.round(50 / this._templateCost), 1, nextIncrease)),
      idlePeriod);
}`

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants