Smarter rendering of the widgets (used to be memory degradation)

[antgonza]

When working with a lot of samples and a lot of columns, it seems that the performance degradates as you change between coloring columns. This is more noticeable when working with gradients. Maybe we need to force the cleaning of variables/objects??

[ElDeveloper]

Hmm I haven't noticed this. But yes, I agree that that could be an ongoing issue.

El 27/08/2013, a las 15:29, Antonio Gonzalez notifications@github.com escribió:

When working with a lot of samples and a lot of columns, it seems that the performance degradates as you change between coloring columns. This is more noticeable when working with gradients. Maybe we need to force the cleaning of variables/objects??

—
Reply to this email directly or view it on GitHub.

[ElDeveloper]

I'm starting to encounter this and I think the culprit is specifically the creation of the color pickers.

[ElDeveloper]

This is not memory degradation per-se. What happens is that when we have a large amount of categories being displayed, that means that there will be a large amount of widgets to render (the sliders for visibility and scale), which by itself is not a hard task to do but when you have a large number of them you can expect the browser to become a little bit sloppy. The solution to this is to not render the widgets unless needed, similar to what's done with the color pickers i. e. you have to click a button to show the selector.

[ElDeveloper]

Additionally, since this is not memory degradation per-se I'm removing this from the milestone and I'm renaming this to have a more appropriate name.

[ElDeveloper]

We should be able to use something like SlickGrid for this purpose. This should make it such that widgets are lazily loaded.