You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Very slow operation in 11.2.0 and higher with large blocks, using "sizeToContent" and crippled cellHeight values #2978
I need all the blocks to be placed close to each other (maximum distance should not exceed 2px) and "sizeToContent" should be used. For this I used cellHeight: '1px' || '2px' and everything worked fine for both small and large blocks. With other cellHeight values, the distance between the blocks vertically will be large.
Up to version 11.1.2 (inclusive) I had no problems with initialization:
Starting with version 11_2_0 and up to 11.4.0, terrible slowdowns begin during initialization. If I specify cellHeight: '50px' or I do not specify cellHeight, then everything will work quickly, but there will be a gap between the blocks vertically.
Your environment
version of gridstack.js - 11.1.2 & 11.2.0 & 11.4.0
which Chrome, Chromium/Windows 8.1, 10
Steps to reproduce
This behavior cannot be simulated on jsfiddle.net, because it requires a large browser window.
On the HTML page, create more than 15 image blocks of size 3840x2160
Expand the browser window to full screen.
and after the page loads, initialize:
Attached is an archive that you can deploy on your server and check the execution speed. In the index.html file, you can connect either 11.1.2 or 11.4.0 gs.zip
Expected behavior
The speed of initialization in 11.2.0 and subsequent versions should not be several (3-10) times lower than in 11.1.2
"addCSSRule" in GS works very slowly
GS wasn't designed to use cellHeight:1px as ton of CSS will be created and collision isn't ideal, but large chunks of blocks for things to line up. maybe use another lib ?
that said, sounds like 11.2 changed the CSS creation and is now slow... I could take a look, but other issue might crop up that won't be fixed...
this is most likely caused by #2852 @lmartorella do you have a suggestion ? suppose we could make the change to #2854
But what to do with this? #2979
What if you want to avoid empty space?
Before version 11.2.0 everything worked fine!
cellHeight:1px is of course rare, but for example cellHeight:5px is a very real value. And with 5px there are also terrible slowdowns...
maybe use another lib ?
:) This is not the best suggestion...
but large chunks of blocks
I just checked on 200x200 images, also terrible slowdowns... Doesn't depend much on the size. Depends on the cellHeight values
Hi,
Yes, you should definitively look to integrate #2854 to avoid stylesheet manipulation at all. Scenarios like this one, with many rows, would benefit in not having O(N) CSS classes where N = rows.
Yes, it is possible that #2852 without #2854 causes performance issues, so if you are not planning to integrate #2854 soon I would revert it.
Thx, L
Activity
adumesny commentedon Mar 4, 2025
GS wasn't designed to use
cellHeight:1pxas ton of CSS will be created and collision isn't ideal, but large chunks of blocks for things to line up. maybe use another lib ?that said, sounds like 11.2 changed the CSS creation and is now slow... I could take a look, but other issue might crop up that won't be fixed...
this is most likely caused by #2852
@lmartorella do you have a suggestion ? suppose we could make the change to #2854
IgorA100 commentedon Mar 4, 2025
But what to do with this? #2979
What if you want to avoid empty space?
Before version 11.2.0 everything worked fine!
cellHeight:1px is of course rare, but for example cellHeight:5px is a very real value. And with 5px there are also terrible slowdowns...
:) This is not the best suggestion...
I just checked on 200x200 images, also terrible slowdowns... Doesn't depend much on the size. Depends on the cellHeight values
lmartorella commentedon Mar 9, 2025
Hi,
Yes, you should definitively look to integrate #2854 to avoid stylesheet manipulation at all. Scenarios like this one, with many rows, would benefit in not having O(N) CSS classes where N = rows.
Yes, it is possible that #2852 without #2854 causes performance issues, so if you are not planning to integrate #2854 soon I would revert it.
Thx, L
Updating gridstack to version 11.1.2
IgorA100 commentedon Apr 9, 2025
In v11.5.0 the problem still remains.
adumesny commentedon Apr 9, 2025
all those changes will be in v12 (next major release) - removing most css (part of #2854). for now use older rev.
adumesny commentedon Apr 13, 2025
fixed in v12 with #2854 and following changes