Writing Performance issues in metaboard v1

[blinkybool]

The problem

After writing a certain number of lines to a board, the writing experience becomes (to quote @dmurfet) "janky". This is likely caused by some operation or backend task taking more time than can fit in a 60fps frame, and so the querying of the pen position as it moves is delayed. This increases the size of each line segment making up the curve, and therefore the resulting curve can have less detailed curvature (it's more jagged), especially when writing quickly.

A second symptom of this performance issue is that it can take longer for the lines immediately behind the pen to appear. This is most obvious when drawing long strokes at a medium pace. It's not clear to me how to understand the timing of when gui elements appear in the lifecycle of a frame, and how performance issues influence this. Would it be possible to have a very smooth curve (lots of pen position queries) that takes a while to appear? Or are these two symptoms, jaggedness and lagginess, essentially the same thing?

In my experience, the issue arises earlier (in terms of line count) on an iPad, v.s. my desktop. It is more likely that this is down to software differences than hardware, as the iPad Pro is certainly capable.

Potential causes

There are a few potential causes of the performance issue, but first we should ground ourselves by using metaboard v0 as a baseline. At the moment the method of comparison is estimating the line counts visually and comparing experiences from memory. Instead we should test by making an equivalent to the randomFigures code for metaboard v0. randomFigures creates random walks, totalling to a certain line count.

With this as a tool, the first possible source of the performance problem can be properly investigated:

• Creating, updating, querying and destroying instances in the DataModel is slow.

While an obvious difference between metaboard v0 and metaboard v1 is that v1 does a lot of recomputing the state of the canvas, this happens mostly on the lua side of things, which runs much faster, and is designed to shortcut as much as possible. The theory here is that v1 is somehow doing more work on the DataModel side of things each frame, so by carefully comparing the DataModel interactions between v1 and v0, we might discover some problematic difference. I have already conducted this analysis to some extent, but there are differences between the instances that v0 and v1 make that I've deemed "unimportant", which perhaps might actually be important.

• UIQuadTree

I managed to do a microprofiler capture of the performance issue on an iPad, and it reveals about 2400x repeated operations that occur within the ProcessInput phase which totals about 6.6ms in one example frame.

Each one of them looks like this

What does this mean? It would make sense if each of these operations correlated to a line Frame on the screen. Perhaps Roblox is trying to check if any of them is being touched by the pen? But none of those frames have any MouseMoved events attached to them, so I'm not sure. I also can't explain what Update QuadTree is about. Supposedly this is the input stage, and I'm not re-rendering the canvas until RenderStepped is called. Maybe the cursor circle gets updated in that stage?

Will add more soon

[blinkybool]

Disruption boards have abnormal performance compared to landau-ginzburg in the same world

[blinkybool]

Closing this for now. We can return to this if performance becomes an issue again.