The gani system was written years ago, well before I shifted focus on m.grl to focus on being a high end 3D engine. 2D mode was eventually deprecated - opinionated drawing APIs were introduced - a new 2D mode was eventually hacked back in again.
There is a lot of legacy code there that doesn't really make sense to keep anymore, and the rest of m.gani.js could then me refactored to be more performant. M.builder.js should also be reviewed, since it is mostly just used by the gani system.
In particular, here is how I want things to behave:
COMMON:
1) Parser reads gani format and generates a more obvious intermediary data structure. This could possibly be farmed out into its own library. If the WebGL and DOM renderer are able to share a caching pipeline, it might make sense to also include that here + some kind of basic functionality to allow for gani widgets without m.grl.
WEBGL:
1) when using the GL renderer, instancing a gani for the first time should use the sprite definitions to generate an atlas image for only the sprites actually used by the gani. A single VBO is generated for each gani. Vertex ranges are used to control which frame is being drawn, and which directional variation.
2) when using the GL renderer, instancing a gain or updating one of its image attrs should cause the atlas to be regenerated via blitting to a canvas. Each unique combination of attrs should have its own atlas, which is then shader by the applicable gani instances.
DOM:
1) when using the DOM renderer, caching might work such that instead you blit out each possible frame into canvases that are then associated to whatever unique attribute configuration.
2) gani's are then drawn as a single div with a single image background
VARIATIONS:
1) It could be the case that the "each frame is a canvas" cache could then be atlased within a reasonable space constraint (within the opengl instance's maximum texture size), and then the code for generating these caches can be unified between both versions.
2) The dom version could make use of multiple background image css to layer sprites up per frame. This should still be reasonably fast, because the animation is still represented by only one dom object. In this case then, having a single image as a sprite atlas could be used for both render pipelines instead of using the frame cache approach. This also has the advantage over non-atlas frame caches, in that different instances of the animation with the same attrs will only use one texture per frame even if they are out of phase.
Issue #184 is a prerequisite to this.
The gani system was written years ago, well before I shifted focus on m.grl to focus on being a high end 3D engine. 2D mode was eventually deprecated - opinionated drawing APIs were introduced - a new 2D mode was eventually hacked back in again.
There is a lot of legacy code there that doesn't really make sense to keep anymore, and the rest of m.gani.js could then me refactored to be more performant. M.builder.js should also be reviewed, since it is mostly just used by the gani system.
In particular, here is how I want things to behave: COMMON: 1) Parser reads gani format and generates a more obvious intermediary data structure. This could possibly be farmed out into its own library. If the WebGL and DOM renderer are able to share a caching pipeline, it might make sense to also include that here + some kind of basic functionality to allow for gani widgets without m.grl.
WEBGL: 1) when using the GL renderer, instancing a gani for the first time should use the sprite definitions to generate an atlas image for only the sprites actually used by the gani. A single VBO is generated for each gani. Vertex ranges are used to control which frame is being drawn, and which directional variation. 2) when using the GL renderer, instancing a gain or updating one of its image attrs should cause the atlas to be regenerated via blitting to a canvas. Each unique combination of attrs should have its own atlas, which is then shader by the applicable gani instances.
DOM: 1) when using the DOM renderer, caching might work such that instead you blit out each possible frame into canvases that are then associated to whatever unique attribute configuration. 2) gani's are then drawn as a single div with a single image background
VARIATIONS: 1) It could be the case that the "each frame is a canvas" cache could then be atlased within a reasonable space constraint (within the opengl instance's maximum texture size), and then the code for generating these caches can be unified between both versions. 2) The dom version could make use of multiple background image css to layer sprites up per frame. This should still be reasonably fast, because the animation is still represented by only one dom object. In this case then, having a single image as a sprite atlas could be used for both render pipelines instead of using the frame cache approach. This also has the advantage over non-atlas frame caches, in that different instances of the animation with the same attrs will only use one texture per frame even if they are out of phase.