Improved rendering speed on Mii Maker

[DanilochTop]

This PR improves the Mii Maker rendering speed by caching all the possible images from a tab before being selected.

Detailed changes

Basically, when the user selects a tab, subtab or page, all the images from that section are cached, including all possible changes that the user can do.
It gets all the inputs in that tab and all the possible values of each.
This improves a lot the speed because when the user input something the images are loaded and ready to be rendered into the canvas!
Also, added some little changes to the mii maker handlebars code, so we only cache what's really needed, to avoid the application to slow down.
The images are deleted after they aren't needed anymore so we don't need to worry about memory consumption.
Also, if the user have a really slow internet speed, the blur effect is still used when needed.

Video demo

2024-05-26.07-45-26.mp4

Any suggestion, feedback or bugs just message me! :)

[gitlimes]

Hello, thanks for your contribution!

While I fundamentally agree with the fact that the speed of the current miieditor implementation is... really bad, I'm not sure that sending so many requests to the Mii rendering API is a good idea. Like, I'm worried they might add authentication or CORS headers (bypassable through a cors proxy, but that could expose us to the risk of our proxy ip being banned).

To be fair though, I'm not an expert with regards to how Nintendo handles many requests, so I'll pass this along to @jonbarrow, who has crashed official Pretendo servers twice.

[DanilochTop]

Hello @gitlimes! Thanks for the reply.
I understand the concerns about this and I'm sure you're totally right.

I think it's a great idea to wait for Jon's response, but here are some important points:

• The code was designed to avoid excessive requests to the Mii rendering API, by caching only the possible visuals that the user can apply in the current tab/subtab/page. There are not many requests if the user is not interacting with the site very quickly (e.g., switching tabs every 100-500ms).
• Nintendo could indeed implement CORS as a protective measure, but I don't think they would do that just because of Pretendo. Anyone can send excessive requests to this API and so far they haven't done anything about it. If they wanted to implement CORS, they would have already done so.

Another consideration that could be taken into account would be to rewrite the API using our own images, which would take time, but I could make a contribution regarding that.

[gitlimes]

You raise good points!

The issue with using our own images is that, unless we were to make our own assets, we'd be committing copyright infringement, which is something Nintendo doesn't exactly... uhh... take lightly.

[jonbarrow]

What is the average number of requests being made per page transition. I agree with @gitlimes about being worried of over using the rendering API. Even just an extra request effectively doubles the amount of traffic we would otherwise send to the API, growing exponentially.

I do agree that it's probably unlikely that they'd outright block things. But I stay in the habit of not stepping on Nintendo's toes. Pretendo as a uniquely positive relationship with Nintendo currently (we were directly involved in getting the December 2023 NN connection issues fixed, for example), and I'd like to keep it that way.

As for the renderer in general, it's important to note that @shutterbug2000 is currently working a new renderer that doesn't use Nintendo's servers at all. Instead it would use our own servers, running the Miitomo Mii renderer either through an emulated Android device or QEMU.

[DanilochTop]

The average number of requests being made per page is 12. Some pages with range inputs require more requests (about 50), like when changing eyebrows position, size, etc. Also, when changing range inputs the images are cached again to apply the changes correctly to all possible inputs in the page.
I totally understand your points. Great considerations.