1

I am creating an image editor for SVG files. Some of the SVG files contain <image> tags, which can make the SVG file very large (around 25 MB or more), this makes these images both slow to load but also slow to edit.

Thinking freely, the best way (I think) to tackle this is to make the editor load a "fake" version of that SVG that is only let's say 1MB. Apart from the difference in size, the "fake" SVG is identical in every way: objects, positioning, size ratio etc.

This "fake" SVG is fast to load, and when the user clicks "Save" I have plenty of time replicating those changes on my real SVG in the backend (yes I want the changes to also apply to the original version).

I have started coding on this solution, namely by storing every edit step:

const stepList = [...pervValue.steps.slice(0, currentStep), canvas.toJSON()]

and loading it to a new canvas

      canvas.loadFromJSON(json, () => {
        turnOnCanvasEvents()
        canvas.renderAll()
      })

However .. my problem is that nothing shows up and this feels like a very cumbersome approach as the JSON strings also get abnormally large after just a few steps. I will attach the JSON structure for one of my "tamer" SVG images.

I am thinking here, am I making things more complicated than they need to be?

JSON structure from canvas.toJSON()

Alien13
  • 558
  • 3
  • 8
  • 30
  • Why not just store the changes at each step rather than serializing the entire canvas every time? – melchiar Apr 13 '21 at 07:04
  • Thanks for the comment, that is good input. This is the format that the function gives me unfortunately canvas.toJSON() (a really bad way of storing changes I agree!). Caching only the changes would make things easier and lighter, not sure if there is a function that will do that for me, or if I need to gets my hands dirty myself. – Alien13 Apr 13 '21 at 07:17
  • And then there is the problem how to let the system know which object in the large image that corresponds to which object in the small image (in order to replicate the same changes). Searching the documentation for a good way to solve this. I think I can use the layer number of the object as an identifier, since it is unique and mutually corresponding in both the small and large image from the beginning. – Alien13 Apr 13 '21 at 07:21
  • 1
    This should help with storing the objects being changed. https://stackoverflow.com/a/19075310/7693185. Yes, the index is a reliable way to track which object is which, provided you keep your list updated whenever order changes are made like bringToFront – melchiar Apr 13 '21 at 14:41
  • Thank you for the link I will have a look. I also feel that index is a reliable way, but still a bit sceptical (I am sceptical by nature), do you know if there is any more reliable way? Especially if I can avoid the whole "bringToFront" and "bringToBack" scenario. I will have a look at the link and see if the new Caching structure can be used to replicate the changes on an identical but bigger picture. – Alien13 Apr 13 '21 at 14:57
  • Or perhaps assign them an ID upon loading, since both the small and the large image should have the same load order. Then we don't have to deal with the bringToFront thing. – Alien13 Apr 13 '21 at 15:53
  • 1
    Yes, IDs will work too (https://stackoverflow.com/questions/30223144/how-to-get-an-object-identifier-in-fabricjs) – melchiar Apr 13 '21 at 17:06

0 Answers0