almosr
commented
8 years ago The idea is great, however, that structural level what you are referring to doesn't exist on the code render level, because it was interpreted by the android-svg library code already.
With some changes on the original library code it is possible to pass more information to the code render and recognize those parts which were processed already. This is rather complicated with the current structure, the concept of subroutines has to be introduced to code render.
I have a map image with a lot of repeating symbols, so I put them inside an SVG symbol tag, so that the same drawing instructions don't have to be repeated over and over again. The result of the code generation process is just a one long code block (sometimes divided into several render functions), which does not take advantage of the fact that the exact same drawing instructions could be grouped together as functions. This way it would be easier to make changes in the code. It would also make the code shorter (the same symbols wouldn't have to be repeated). The only problem with this solution is that you have to keep in mind that each symbol instance may have different matrix transformations, but it shouldn't be too hard to code up (I did it with my generator and it worked well).