feat: add basic render queueing

[BeksOmega]

The basics

• I branched from develop
• My pull request is against develop
• My code follows the style guide
• I ran npm run format and npm run lint

The details

Resolves

Fixes #6130
Work on #6786

Proposed Changes

Adds a render queue that is used to delay / batch block rerendering. See #6786 for info about what exactly this means

Reason for Changes

5x performance improvement!

Test Coverage

Only manual testing.

Documentation

N/A

Additional Information

There are some things in core that need blocks to be rendered immediately. E.g. flyouts need blocks to render immediately so that they can then be positioned. So I only converted dragging / connecting / disconnecting to use the queue, and we can convert other things over time.

This did run into some problems with the connection database, because rendering blocks after a delay means their connections have moved a bit before the normal call to tighten happens. Which is why we need to updateConnectionLocations on all blocks, even the ones that haven't been rendered. So we might need to pull this change out if it causes other unfound problems related to that.

On the other hand, I think our connection tracking is badly understood and overly complex. So I might look into cleaning this up a bit. E.g. why does tighten look at the relativeXY of the block when it can just calculate the offset based on the offsetInBlock_ of it and its parent connection?

On the other other hand, touching the connection stuff is scary :P

[ewpatton]

@BeksOmega We implemented something similar in App Inventor. One additional challenge we ran into was dealing with the connection database where it devolves into insertion sort on large updates to the workspace (such as clean up blocks), so we also included a mechanism to defer updating the DB and then used the built-in sorting capabilities which are O(n log n).

[BeksOmega]

@BeksOmega We implemented something similar in App Inventor. One additional challenge we ran into was dealing with the connection database where it devolves into insertion sort on large updates to the workspace (such as clean up blocks), so we also included a mechanism to defer updating the DB and then used the built-in sorting capabilities which are O(n log n).

Ooo good idea!! I'll have to see if that's workable here :D

[BeksOmega]

@BeksOmega We implemented something similar in App Inventor. One additional challenge we ran into was dealing with the connection database where it devolves into insertion sort on large updates to the workspace (such as clean up blocks), so we also included a mechanism to defer updating the DB and then used the built-in sorting capabilities which are O(n log n).

So I was looking into this some more, and I'm confused about how it devolves into insertion sort. splice is constant for low numbers. calculateIndexForYPos_ is O(log n). findIndexOfConnection_ does have a linear component, but if your workspace is distributed vertically, it should essentially be O(log n). So in general, I think reconstructing the database from scratch should be O(n log n) using the current algorithm(s).

Does it devolve into insertion sort only when your workspace is arranged horizontally? or am I missing something here?

[cpcallen]

This method doesn't have very many callers, and they are all in either block_dragger.ts or rendered_connection.ts. Do you think indirecting via BlockSvg.prototype.queueRender (rather than calling render_management.ts's queueRender directly) is justified on redability or other grounds?

[BeksOmega]

Later changes make several more calls to this, so I think it is justified on grounds of readability. Plus, it's internal, so the maintainance cost to including it is minimal :P If we want to tear it out later we can!