Memory overload

[j-te]

After subsequent batches there are reports of the app crashing. I suspect this may be down to states/vars holding large amounts of data. I'm yet to have a look myself in detail but have experienced a couple myself.

There are discussions on the forums of moving ops into workers for other reasons: this may be beneficial for the zipping/processed results.

Personally I think we should remove the ability to continuously batch. Reason being is there is no real need to cache previous results and it presents memory challenges. I propose each subsequent batch is cleared each time.

This is a UX change so it's good to discuss options/investigate more?

[eldinor]

Sure, for the sake of memory it is better to clear a cache.

[eldinor]

Still from the user side it could be convenient to check the same GLB file with different optimization settings.

[j-te]

Good point. I have been thinking about adding a 'reporting' feature which is a detailed breakdown analysis of the file properties (before and after optimisation). The reporting data could be persistent, even saved in user storage. Major UI/UX considerations here and work to do. Rows in the report could contain a file hash column and be sortable (simple table filtering).

[eldinor]

Could be useful to have different optimization settings shown for the same GLB file in a row, in order to choose between them for a subsequent batch of a set. But probably it would be too complicated at the moment. Or it could be done in a separate mode.

[eldinor]

As for reporting, I did the small "report" at https://screenshoter.babylonpress.org/ (only minimal info and screenshot).
The function is as simple as possible - https://github.com/eldinor/GLB-Screenshoter/blob/f5d8b486ed0bff343377e6c6efb93b802ec435cf/src/components/ModelGallery.tsx#L52