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

Performance issue with multiple paper-swatch-pickers #30

Open
z2oh opened this issue Nov 15, 2017 · 0 comments
Open

Performance issue with multiple paper-swatch-pickers #30

z2oh opened this issue Nov 15, 2017 · 0 comments

Comments

@z2oh
Copy link

z2oh commented Nov 15, 2017

Description

This isn't really a bug, but more of a general concern that I didn't see mentioned anywhere in the docs.

We built a theme editor inside our application that allows users to customize the colors of the application. These are applied through CSS variables. We currently have 29 variables that can be customized. The theme editor code looks something like this:

<template is="dom-repeat" items="{{colors}}" as="color">
    <div id="item">
        <paper-swatch-picker id="sample" horizontalalign="right" color="{{color.value}}" on-color-changed="applyToTheme" noink></paper-swatch-picker>
        <paper-input id="input" on-input="applyTotheme" value={{color.value}}"></paper-input>
    </div>
</template>

Sometime after making this we realized we had some serious performance issues. I made a small modification here to test a theory:

if (gd._count === 0) {
    var options = !isMouseEvent(dep) && PASSIVE_TOUCH();
    node.addEventListener(dep, this.handleNative, options);
    if(!window.count) {
       window.count = 1;
    }
    else {
        window.count = window.count + 1;
    }
}

With the <paper-swatch-picker> removed from the theme editor code above, window.count was a modest 200. With the <paper-swatch-picker> line re-added, window.count was... 21428 ! With 29 color pickers, that means each color picker is adding 732 event listeners which is almost 4 times the rest of our application combined. This severely impacts the load time of our application.

This isn't exactly a bug or an issue with paper-swatch-picker, but I was surprised to not see a warning about this performance impact in the docs. I know that we can reduce the number of columns in the picker, but that sacrifices some functionality. We can also defer the loading of the theme editor until the user opens it, but then opening the theme editor will take a long time. What is the recommended way to include multiple swatch pickers on a page without killing load performance?

I think for now we will look into a way to have our variable color selectors share the same paper-swatch-picker which would presumably increase performance drastically.

I should add, we are using Polymer version 1.11.0.

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

1 participant