¿Alguien más tiene fallo en el sistema con retraso al mover los bloques de 4-5 segundos?

[Eliel_Guillen]

Tengo problemas con la página, no carga rápido y tiene un retraso de 4 a 5 segundo en cada movimiento de los bloques, ¿alguna solución o es en los procesadores generales?

[SteveJG]

@Eliel_Guillen

is there any solution or is in the processors general

Perhaps.

What happens with the ability to reposition the Blocks on the Designer quickly is related to:

• the size of your Project. Updating a large Project takes longer than updating a small Project.
• the number of Blocks in your Project. Use fewer blocks; reuse code
• the Browser you use to design you Project. Chrome is good but most users agree Firefox renders Blocks faster. Switch to Firefox might improve your Block refresh/movement.
• your Internet connection speed
• your PC cpu chip
• usage of the MIT App Inventor server. During periods of heavy usage some developers will find activity slow. Solution is to try again later when usage may be at lower levels.
• other factors.

[Eliel_Guillen]

Muchísimas gracias, a la perfección con firefox, estaba trabajando con Chrome pero definitivamente es mas rápido fire, muy amable por el tiempo otorgado. Saludos.

[ABG]

When you have too many blocks spread out over too large a surface area,
the Blocks Editor hits a complexity limit when it tries to generate a blocks.png file for the screen.

There are two main approaches to deal with this:

• Start a Google Doc with a Table of Contents explaining your app, with sections for Design, Data, Code, including Downloaded Png images of all Events, Procedures, Globals, and with html cross-links for easy navigation. Such a doc becomes easier to read than a complete blocks image, because you have FIND, Next, PREV, back functionality, and you can add paragraphs of commentary around your code. This is my preferred life saver when doing a very large complex app. If you go this route, try to arrange your blocks geographically in a column matching the order of your Table of Contents, then do periodic Clean Up Blocks to pull them inline. This sometimes lowers the load on the Blocks Editor.
• Reduce your block count:
  • Use parametrized procedures for common code
  • Use Media text files instead of big clumps of text blocks
  • Use generic blocks instead of repeating component event blocks
  • Encode repeating decision patterns into lookup tables loaded from Media csv text files (does your blocks image look like a box of combs?)