Create Gym Images Dynamically

[michikrug]

Description

This PR introduces dynamic gym image generation by using a canvas element and composing multiple image elements into the final gym image / marker.

Motivation and Context

Currently all gym images in combination with all raid levels and raid bosses have to be provided.
Since we already have all the information and images available to compose them dynamically, this PR does so.

It only adds new egg images to be included in gym images with raids.
The gym and raid level badge is automatically rendered using a circle and the number.
The raid boss images are extracted from the large sprite we already have (also can be replaced by other ones, but may need some changes in the rendering size).
All images are added to the appropriate base gym image from the current team.

Furthermore, an option (by default activated) to cache the generated gym images in the Store is provided. Thus, every combination only has to be generated once and then is used from the cache (LocalStorage).

How Has This Been Tested?

Tested on own instance without any errors.

Screenshots (if appropriate):

Gym images render nearly identically to the previous ones. With the following exceptions:

• Eggs look bit different, since i do not have the sources of the current ones.
• Raid boss badge does not have the black border as before, since the images from large sprite are used.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

• New feature (non-breaking change which adds functionality)

• Breaking change (fix or feature that would cause existing functionality to change)

• My code follows the code style of this project.

• My change requires a change to the documentation.

• I have updated the documentation accordingly.

[pogo-excalibur]

This is an interesting approach.

It's somewhat tangential to #2348 though - would you mind outlining the advantages that this method has over the single spritesheet aproach which that PR uses?

[michikrug]

@pogo-excalibur probably none, just a different and less expensive way

[Levonestral]

I could be wrong, but the one major advantage I see in this PR over 2348 is that we'd no longer have to wait for official code changes to be made each time a new raid boss is added; which actually seems to be more frequent lately. This approach makes the entire raid updates process hands-off and hassle free.

I looked over 2348 and didn't see this as being in there, but could have missed it. Instead, it looks like each time something new is added to the raids, we'd still have to wait for official code changes and then rebuilt the spritesheet each time?

Is it possible that you could remove the gym generation from 2348 and allow this PR to do that work instead, leaving 2348 to handle "everything else" ?

[michikrug]

This is true. Thanks for pointing that out.

[michikrug]

In my map I, e.g., added also an "is in battle" icon in top

[KartulUdus]

This fascinates me, could add EX mark after #2440.
Also probably breaks much of it

[michikrug]

@KartulUdus Thanks for the idea, just implemented it :)

[Alderon86]

@michikrug we had an 'is_in_battle' approach ongoing but stoped due to wrong image size and lazyness.
Could you pr that one also?

[captbunzo]

Personally I much prefer this approach. Eliminating the need for code changes after new raid bosses are added is a great feature of this version

[michikrug]

@Alderon86 Sure. I just do not know if this is wanted in RM.

[michikrug]

@Alderon86 you may check #2500

[sebastienvercammen]

Clarification per previous comments: this PR isn't a less expensive way to build the images, just a different one.

• LocalStorage limited to 2MiB or 5MiB of storage on most browsers (including mobile).
• No compression or browser optimizations for images stored as data strings in LocalStorage.
• Still requires the visitor to download each icon at least once. If the host hasn't set up a reverse proxy with nginx/apache2 browser caching headers, it's possible that the visitor will redownload the same icon several times if it's used for different image types (e.g. different gym levels) between several visits.
• Each client will have to redraw the images. Although this doesn't affect other clients, it's something we need to be aware of: a process that is currently only being done once (spritesheet gen), will then be done once for each visitor.
• Heavy for mobile devices.
• If image cache is disabled or unavailable (unsupported, LocalStorage full), there is no performance gain or caching.
• If LocalStorage ever gets filled, we break the entire Store, which will break all map settings.
• Separates gym image generation from Pokémon image generation. We should have one process for all images/spritesheet generation/deployment instead of several ones.

However:

• Doesn't need code or spritesheet updates. Easier maintenance.
• More flexibility than the current spritesheet gen (combining/overlapping images). Also solved with the other suggestion for dynamic spritesheet generation.

Tagged "to be checked" for discussion.

[michikrug]

@sebastienvercammen Thanks for the summary.

I also tend to do the image composition on the server side using an additional endpoint that takes the same arguments as my function currently. That would preserve the same advantages but gets rid of some disadvantages you stated.

Maybe we also find a nice way to combine the rework of the spritesheet stuff with some of the ideas introduced here.