I want to show no disrespect or impatience with this post. I really appreciate the work of everyone that puts time in to making Kodular (and other platforms), pushing out updates, fixing bugs, making extensions and everything else. It’s opened up a new hobby for me and I’m really greatful for that.
Is there something wrong with Kodular? I know it had been facing some server issues in the last few months but I thought that had been solved recently as the warning is no longer there. I’m trying to work on a couple of my apps and it’s nearly impossible to get any work done. Some days everything is really smooth and responsive and other days I just decide to give up as I can’t feasibly do anything.
I try to drag blocks around the screen and it takes 5-30 seconds to place a block. Even interacting with the Kodular menu buttons is unresponsive. I respect that my apps are probably poorly optimised - I have around 3000 blocks and about 50 components but I only use 1 screen and this issue hasn’t been as bad in other app builders. When I try to use the Kodular Companion app and edit the app at the same time it’s even worse, which makes me think it’s a server/network issue.
To rule out it being my hardware/connection, my laptop is i7, 16gb ram, 512gb ssd and a speedtest.net shows 29 ping with 25Mbps download and 5Mbps upload. I’ve tried Chrome, Firefox, Edge and IE and all have similar issues.
Is this a server issue at the moment or is it something only affecting me? Perhaps it’s because I ported from Appybuilder (after deleting incompatible extensions first)? If anyone has any tips for how I can improve the responsiveness, please let me know.
Hi. Thanks for reaching out.
We’re sorry to hear you’re having performance issues. From what I can tell, it seems to be an issue on your device as block drag/drop is handled by your computer and not our servers.
Could you please give us more details about your project (number of blocks, screens, etc.), and if possible, a sample AIA?
Also, do these performance issues exist when working on a blank project? If not, at what number of blocks/screens does the Creator begin to lag?
Does collapsing unused blocks help speed up the Creator? You can right click a block to open a drop-down menu and then select “Collapse Block” to collapse it. Collapsed blocks do not render, meaning your browser will not have to worry about them. Maybe this helps reduce the lag?
The truth is the blocks editor is not optimized to work with large projects. Some webapps can move and pan complex vector graphics way faster. I guess this is due to the fact that originally App Inventor wasn’t meant to be a professional programming platform and having thousands of blocks wasn’t a concern. But I think a major update to the way Blockly renders the active view is way overdue.
I think the app inventor is working on improving the speed of the block editor, but I’m not sure if it will be available any time soon, 
here: BlocklyPerformance.pptx - Google Drive
I don’t know how Blockly rendering works but maybe unclicked blocks can be inactive so it only uses system resources for the block that you clicked, so a project with a lot of blocks and a project with less blocks can have same performance. Because it is abnormal to see performance issues with a lot of blocks.
I think Blockly renders the whole blocks area everytime you move it. They should come up with a way of rendering only what’s visible or will be visible in the next frame. The same concept of first person shooters. If those games rendered the whole map in every frame, it would be impossible to play.
I’m not sure if Blockly can do much about it. How block SVG paths are rendered is completely up to the browser you’re using; meaning we often see sharp performance differences them (Firefox has been seen to be much faster than Chrome).
The problem is that Blockly manipulates the DOM directly, thus forcing the browser to repaint the entire screen when the workspace is dragged around. A canvas-based workspace would’ve been much better performance-wise (not sure why Blockly wasn’t written that way) considering we would then have been able to control precisely which pixels are to be repainted.
Moving blocks around, though, shouldn’t put much strain on your browser. Blockly uses CSS transforms to place blocks when the mouse is held down, and changes their actual x/y coords only after the mouse has been released. Browsers often GPU accelerate CSS transforms, so you should see much better performance if you have a dedicated GPU.
Chrome 79 has released a new attribute called renderSubtree (New in Chrome 79 | Web | Google Developers) which we can use to stop Blockly from rendering blocks out of the visible workspace/blocks with collapsed parents.
But we’d still be leaving out everyone else not using Chrome or Chrome 79.
If I remember correctly, App Inventor is working on a new rendering paradigm for Blockly which lets us render only those blocks visible to the user. I don’t seem to be able to find the link now, but it promises significant performance improvements.
yes im also having this problem. im having just 800 blocks and its lagging a lot. takes 5-10 seconds to put a block in position. it was never witnessed in last 2 years .
So I’ve tried collapsing all of the blocks but it doesn’t make much difference to the speed of moving them around. Since the last update things do seem a bit more responsive though. If there are any other solutions to this I’m happy to try it out. Working with small projects feels so smooth and getting things done takes a lot less time.
