Page with long list of images, edit with image editor, memory problem

[Nomia]

Hello,

Our product has a page with long list of images, our user(mostly a teacher) will edit these images with tui.image-editor to mark error area or score on the images.

After the teacher edited 40 or more images, the page will refresh automatically even the editor instance destroyed every time after the teacher finished editing.

We optimized for this by reducing(remove) the invisible dom(images). It will not refresh now. We are so happy. Our users are so happy!

But,

there is still a problem, after our user(the teacher) edited 40 or more images, the tui editor cannot load the image anymore(onto the canvas). We think it's a memory problem. It will occur then the device in a low memory status.

This problem are not easy to reproduce.
We are hoping that you could provide some optimizing ideas.(not fix it)

Thanks!

[auto-comment]

Thank you for raising an issue.
We will try and get back to you as soon as possible.

Please make sure you have filled out issue respecting our form in English and given us as much context as possible. If not, the issue will be closed or not replied.

[jinwoo-kim-nhn]

Thanks for the problem. In addition to the improvement plan, we will take a closer look and improve it.

It may help to improve the execution environment, especially if you provide information such as browser type, version, and os. Also the version of the image editor.

Are you using the destroy method to destroy an instance? I need more information.

For example, did you create 40 instances at the same time? Or is it still loading different images from one instance?

[Nomia]

Sorry, here is the env

Browser: embed browser in app(webkit)
System: Android Or IOS, even on Windows(webkit)
Version: 3.8.0

And yes, we use the destroy method to destroy an instance.

We wrap tui.image-editor in a Vue component.

The component will be created every time a user click edit button, we init the tui.image-editor instance when the component mounted.

The component will destroy itself when it's unmounted. And we will manually destroy tui.image-editor instance before the Vue component destroy itself.

So every time there would only be one tui.image-editor instance on the page, not 40 instances.

[Nomia]

We thought the memory problem might be caused by Vue's virtual dom diff process, because it's a long complex component list.

But if the user never use our image editor that is wrapped with tui.image-editor, the auto refresh will never happen.

We thought the auto refresh problem was solved two days ago by removing the invisible dom/component. But, we reproduced the problem today. If a user with a certain device keep editing images with tui.image-editor the page will definitely auto refresh after 20 or more image editing. But if the user never use the image editor, and just do some other non-image data manipulation, the page will not auto refresh, tested many times. In one test, we try to edit one image after a long time non-image data manipulation, the page refresh immediately.

[Nomia]

certain device is an old device: iPhone 6, inner app webview

[jinwoo-kim-nhn]

Bugs in the imageEditor.destroy() API have been improved by fixing in tui-image-editor 3.9.0.

vue wrapper has 3.8.0 applied, so it needs update.

It will be reflected in the vue wrapper soon, so I think you can check it out at that time. If you are in a hurry, you can fix dependency version package.json directly and install it.

[Nomia]

Glad to hear that!

So you mean all the memory problem are mostly caused by bugs in imageEditor.destroy()(3.8.0)?

[jinwoo-kim-nhn]

This was most likely because the event was not cleared when destroying at 3.8.0. It's hard to say that there is only one cause, but I hope it helps.

I need more time to find everything in depth, I'll do it soon.

[Nomia]

Bugs in the imageEditor.destroy() API have been improved by fixing in tui-image-editor 3.9.0.

I've tried destroy method of editorInstance in v3.8.0 without error. I don't know what is the bug ?

Is it a bug within toast-ui/vue-image-editor or is it a bug within tui-image-editor?

thx

[Nomia]

After I digged into @toast-ui/vue-image-editor, I found that the component itself will destroy the edtior instance, without error.

So, what's the problem with destroy method

[jinwoo-kim-nhn]

#334
sorry. If this isn't the problem, I'll look for more causes.

[fjwong]

Hello,

First of all, thank you for the work on this library. I have been using it a lot in one of my projects.

The project in question has a similar setup as the one described here (Vue.js + https://github.com/nhn/toast-ui.vue-image-editor with a long image list) and I have been experiencing a similar issue, particularly after opening a few large images in iOS Safari.

I’ve submitted a PR that seems to have solved the issue for me at #495.