The more blocks you have , the slower the editor is - with bigger lag times.
I currently have 1131 blocks and the lag times from clicking to a response is about 5 seconds, and it is getting worse.
I had the same issue with “app inventor” a few years ago and eventually gave up with it, so I was hoping this problem would have been ironed out by now but it appears not.
As soon as you have more than a few hundred blocks the editor starts to get very frustrating and pretty much unusable.
Do other people have the same issue ?
If so Is there an effective work around ?
Is anything planned to reduce the lag times ?
Is the problem caused by the auto save feature ?
1 Like
When I started using Thunkable last year, I had the same problem with lag. And it got severe right around where you’re noticing it, 1000 blocks or so. But I haven’t any real slow downs in the past few months.
What browser and OS are you using?
Chrome - Windows 10
Same using Edge
@tatiang - So are you saying the problem doesn’t get any worse than it is at around 1000 blocks, or do you have no lag at all any more ?
I’m saying I don’t notice any lag. I’m using Chrome on a Mac, OS X 15 and 16.
Here’s a screencast of a project with 2045 blocks (no sound). I think the Screencastify software interfered with the mouse clicks a bit so you’ll see me struggling to grab one of the blocks but that’s mostly on me.
The screencasting is also undoubtedly adding lag to the video but you’ll see that I can drag blocks around and at most it takes half a second to move to a new location.
2 Likes
Hey @paulbthatsme,
There’s has been a lot of work done on blocks editor performance in the past, but hopefully we can help you improve this situation.
As a first step, I’d recommend optimising your blocks as much as possible, i.e using functions
There should be some examples in #thunkable-tutorials about this.
Hi @domhnallohanlon - When you say use functions, is this to try and reduce the overall number of blocks, or does putting blocks within functions help with the lag - even if the total number of blocks is not reduced ?
Just trying to understand if the lag is purely caused by the number of blocks or if the type of blocks also affects things.
Regarding functions…
I have a situation where I have 4 fire button sprites that relate to different tank sprites.
For example - Fire button 1 relates to tank 1
So I have to repeat the above set of blocks for each fire button.
I have managed to change this to the following…
So I now check when a sprite type is clicked and get an unused property - drawing width - to determine which fire button is clicked and then call a function.
But the function still has to have several if blocks relating to the firebutton clicked…
Is there a better way to do this so I don’t need all the if blocks ?
Its a shame you cannot have an array of sprites, that would make it much easier.
I actually can’t see that last screenshot (it’s quite blurry for me?)
But from the shapes/patterns I’d say so.
Possible to upload again?
So I am checking the fireid and using that in if blocks
It seems a bit of a clunky way to do it but I cannot see any other way. An array of sprites or an array of any sort of component would be very useful and would cut down the amount of blocks needed greatly, as I am having to replicate a lot of blocks with just the component names different in each case.
Or if there was a way to get a components id. So for example I could have a block “When Fire1 clicked” which could then get the id of Tank1 and Bullet1 and pass those through to a function.
