Bullet overlay performance

[cohlexyz]

I know you're already aware of the issue but here's my two cents

• The bullet texture is fairly big, my guess is if the image was about the size one bullet takes up on screen it might help with performance.
• The text on the bullets requires a decent amount of resources, since it's hard to read anyways it might be an option to either remove it or remove it after a certain amount of time.
• I don't know if the overlay runs in the VM or on your host but if it's the VM and there's no GPU assigned to it the browser source will obviously have trouble with all the bullets since it's using software rasterization.

After some quick testing it seems to mainly be due to the text:

With text:

Without text:

Roughly the same amount of bullets in both.

With bullet text caching (courtesy of ChatGPT):

Still not ideal but a lot better. I guess removing from the cache after a timeout would be even better. It would also make the bullet pile a bit more visible instead of being buried behind all the text.

[y-a-t-s]

My impression is that this has to do with every single bullet in the pile being tracked for gravity. I was giving this some thought earlier, and was thinking the older bullets (the lowest in the pile) should update at a much longer interval than newer ones that are falling or are near the top.

Unless my eyes are deceiving me, you can see them slowly sway back and forth in the pile at rest. All of those computations can't be cheap.

[jaw-sh]

yeah, lower bullets need to be made static. they do sleep eventually but wake up from inputs. statics don't.

[y-a-t-s]

afaik, any JS animations will be running single thread with timesharing. So the main focus should be cutting down on computations per second. Making older ones static would work fine for this, but I feel like spacing out the refresh interval as the bullet "ages" would look a bit more natural. This would also eliminate the need to establish if a given bullet will ever have a chance of eventually moving/sliding.

[jaw-sh]

completely overthinking it. the problem doesn't start until there's over 100 bullets. i just need to think of a way to determine which bullets are the most buried.

[y-a-t-s]

I'm aware it's a problem of scale. My point is you don't have to figure out a way to determine that if you just scale refresh interval based on age. While it seems like overthinking, imo it requires the least thought overall.

[cohlexyz]

I mean as my test showed (which i hopefully didn't fuck up) it's ultimately the text rendering. It roughly takes 59ms out of the 62ms frame time for a fairly large pile. Every bullet's text is drawn individually every frame:

stream-nexus/src/js/matter.js

Lines 131 to 159 in 07922a4

	Events.on(render, 'afterRender', function () {
	var ctx = render.canvas.getContext('2d');
	var allBodies = Composite.allBodies(world);
	// Draw labels for objects that have them
	for (var i = 0; i < allBodies.length; i++) {
	var body = allBodies[i];
	if (body.label && body.label.text && !body.isStatic) {
	ctx.save();
	// Position text above the object
	var x = body.position.x;
	var y = body.position.y;
	// Translate to the object's position and rotate to match its orientation
	ctx.translate(x, y);
	ctx.rotate(body.angle + Math.PI / 2);
	// Set text style
	ctx.font = '12px Verlag';
	ctx.fillStyle = body.label.color || '#ffffff';
	ctx.strokeStyle = '#000000';
	ctx.lineWidth = 2;
	ctx.textAlign = 'center';
	ctx.textBaseline = 'bottom';
	// Draw text with outline (relative to rotated coordinate system)
	ctx.strokeText(body.label.text, 10, 6);
	ctx.fillText(body.label.text, 10, 6);

So when a bullet becomes static its text should also be drawn into a separate texture that contains the username text for each static bullet. Then you'd just have to draw the text for any non-static bullet and one big texture that contains the text for all static bullets and it would avoid all the extra calls to strokeText and fillText.

[jaw-sh]

The check should also check for sleeping. Maybe also a check to see if it has moved more than a certain distance since last update.

[jaw-sh]

After experimenting it appears that the current way of adding text is per frame and that cannot be easily changed. The canvas does seem to clear everything each update.