Use deterministic flushing when building web demo .rrd files

[emilk]

What

I saw this in #3063

and spotted several problems:

A) there was nothing in that PR changing the .rrd files
B) the comparison format uses way too many decimals
C) the comparison uses "KB" which isn't a unit

The first problem should be fixed by turning off time-based batch flushing (first commit).

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested demo.rerun.io (if applicable)

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[jprochazk]

The entries saved in GCS use MB, so comparing against previous entries won't work

[emilk]

let's delete the existing entries then

[jprochazk]

I guess the easiest thing is just to delete the old data and start over instead of hacking in support for both somehow

[github-actions]

Size changes

Name	Previous	Current	Change
Wasm	(none)	13.5 MiB	+100%
JS	(none)	107.7 kiB	+100%
arkit_scenes.rrd	(none)	40.35 MiB	+100%
detect_and_track_objects.rrd	(none)	55.22 MiB	+100%
dicom_mri.rrd	(none)	63.36 MiB	+100%
dna.rrd	(none)	0.62 MiB	+100%
human_pose_tracking.rrd	(none)	55.58 MiB	+100%
plots.rrd	(none)	0.19 MiB	+100%
structure_from_motion.rrd	(none)	6.83 MiB	+100%

[emilk]

This is unreadable - why is it using kiB for such large files? I suggest we use bytes in the GCS store and then chose the unit dynamically based on the scale of the value

[jprochazk]

I suggest we use bytes in the GCS store and then chose the unit dynamically based on the scale of the value

I'm not sure how well the github pages graphs would cope with that

[emilk]

Oh I see… well let's use MiB for .rrd files then

[jprochazk]

why is it using kiB for such large files?

All we need to do is remove the explicit units set in .github/workflows/reusable_track_size.yml

[jprochazk]

That works too