We may decide to migrate to IDB all the way later.įor server-persisted images, we upload them to Firebase Storage (an object store), both for collab and shareLink cases. For now we still keep using LocalStorage for non-image state because it's faster to read from LocalStorage than from IDB (for cold starts). We store the image id to the excalidraw element ( fileId), and the image's DataURL to App.files which is an object of Record where BinaryFileData is an object containing the DataURL and some metadata for the file.įor persisting the image files locally in the browser we use IndexedDB because LocalStorage is way too small (5MB). When syncing changes, or saving element data to server, we don't want to unnecessarily transfer the image data every time.More than one identical image can be on scene at the same time (especially true when people start using SVGs as libraries) which would duplicate the amount of data.Image elements ( ExcalidrawImageElement) do not contain the image data itself for at least 2 reasons: (Note that base64 is around 33% larger than binary encoding - so we if we cared about size, we'd need to dispense with JSON files and start exporting binary files). excalidraw) and not care about decoding on restore. When dealing with local data, it can be set to DataURL).Īnother benefit of DataURL is it doesn't need to be re-encoded when saving to JSON, which means we can just store it e.g. To create that img element, we'll need to set its src to something. One of them is to create a HTMLImageElement and draw it on canvas using context.drawImage(). We use this when rendering the images on canvas (there aren't many way to do that. Get the file's DataURL (it looks like this: data:$). By default we use the SHA-1 hash of the file. Generate an id for the image so it can be referenced later. When you import an image onto the scene, we do 2 things with the file: Fix #19, replaces #3424 (more or less completely rewritten)
0 kommentar(er)
