1

I'm developing an Angular/ Typescript application that makes use of the Autodesk Forge viewer to display building models on smartphones and tablets. The application itself runs smoothly, but the problem occurs when I close the application. After closing the application, I notice that hardly any memory gets released, as can be seen in the image below (I close the application around the 8 seconds mark) and after opening the viewer for two or three more times it will run out of memory and crash. enter image description here When I close the application, I call both the tearDown() and the finish() method as described in the Forge docs and set all possible references to the Forge viewer to null, but they memory leak still persists. This is the main chunk of my viewer code:

this.initOptions = {
    path: 'url to model',
    env: 'Local',
    useADP: false,
    extensions: [],
};

Autodesk.Viewing.Initializer(this.initOptions, () => {

    this.onEnvInitialized();
});

private onEnvInitialized() {

    this.viewer = new Autodesk.Viewing.Private.GuiViewer3D(this.viewerContainer.nativeElement, {});
    this.viewer.initialize();
    this.viewer.loadModel(this.initOptions.path, {}, (doc) => {
        // further forge viewer execution here
    }, (errorMsg) => {
        console.log(errorMsg);
    });
}

public ngOnDestroy() {

    // remove all eventlisteners
    this.initOptions = null;
    this.viewer.tearDown();
    this.viewer.finish();
    this.viewer = null;
}

Is this a known issue and/ or is there some way I can manually release the memory used by the Forge viewer after closure? (It is part of the use case that I have to be able to open more than three viewers after each other in one session.)

Update [19-09-17]

I tried opening my viewer in a fresh, empty angular2 project, and although less memory is being used in general, the same behavoir of not clearing the memory still applies, as can be seen here. I do notice that the event listeners are drastically reduced now. I also updated the Forge Viewer to version 2.17, and the same issue still applies here as well.

sjoerd216
  • 1,326
  • 1
  • 9
  • 15

2 Answers2

0

What version of the Viewer are you currently using? Here you can see a list of the recent changes on the viewer version, v2.17 has a Memory Limit ON by default.

https://developer.autodesk.com/en/docs/viewer/v2/overview/changelog/

Also the version of the viewer can be checked if it is not been defined from the console by typing LMV_VIEWER_VERSION

halfer
  • 19,824
  • 17
  • 99
  • 186
Jaime Rosales
  • 1,106
  • 1
  • 6
  • 8
  • Hi Jaime, I am currently using version `2.13` of the Forge viewer. I have already experimented with newer versions of the viewer, but that broke most of our event handling, so I ended up reverting back to 2.13 in the end – sjoerd216 Sep 18 '17 at 06:00
  • Hi, I will suggest try to move up to a newer version in order to address the Memory leak problem you are experiencing. What kind of problems are you currently having with the Viewer that breaks your events handling? I don't believe there is anything that can be done in order to address this without the upgrade to a newer version. – Jaime Rosales Sep 18 '17 at 17:02
  • After upgrading to 2.17, the `FINAL_FRAME_RENDERED_CHANGED_EVENT` did not trigger anymore in the project. we use this event listener together with the `GEOMETRY_LOADED_EVENT` to determen when the viewer is ready for use. But since the first event never fires, the application will get stuck waiting for the event to fire. Is there an alternative for this event handler or any other way to know when the model is fully loaded? – sjoerd216 Sep 19 '17 at 06:00
  • Hi, I've tested `FINAL_FRAME_RENDERED_CHANGED_EVENT` event with `v2.17` and `v3.1.1`, it works fine on my side. Would you mind providing a reproducible case (**pure forge app without the angular framework**) demonstrating that to `forge.help@autodesk.com`? **Please remove confidential data from anything you provided before you sent it to us**, Thanks! – Eason Kang Sep 21 '17 at 01:56
  • Hi @EasonKang, I send a plain JS version of our viewer to the autodesk helpdesk. Hopefully this helps. I did notice that the event occasionally doesn't trigger (about once every 5 times you open the viewer). – sjoerd216 Sep 21 '17 at 07:56
  • Hi, thank for the information. I'm investigating what happened to your case and will get you back from the Zendesk A.S.A.P. – Eason Kang Sep 21 '17 at 13:32
  • @sjoerd216 you mentioned a problem with `FINAL_FRAME_RENDERED_CHANGED_EVENT` that was logged and fixed on `v3.3`, is this still a problem? which version are you using? – Augusto Goncalves Apr 11 '18 at 18:43
0

The problem remains with version 3.3.5 of the forge viewer. The issue however seems a bit deeper. It looks like when calling viewer.finish() it doesn't release any GPU memory used for the textures.

We call this function everytime you navigate away from the page with the viewer as angular destroys the canvas in the DOM. I would expect .finish to also remove the textures from the memory. Is there any other function that can be called to completely unload any model and textures?

Here are some screenshots where you can see the memory buildup.

Initial initialisation of the page

after returning to this page after closing it

after returning to this page after closing it a third time

  • If you have a new question, please ask it by clicking the [Ask Question](https://stackoverflow.com/questions/ask) button. Include a link to this question if it helps provide context. - [From Review](/review/low-quality-posts/18751209) – Nicolas Labrot Feb 07 '18 at 14:39
  • Its not a new question, its an extension on Sjoerds question with more data.Its related to exactly the same issue in the same app as Sjoerd. – Patrick Kersten Feb 08 '18 at 08:17
  • You put as an answer a question, new or extension, please understand it's not the place – Nicolas Labrot Feb 08 '18 at 16:25
  • I hope I understood what you just said. Im unable to post the additional info up as a comment so I had to resort to doing it as a question. If there is an other way of doing this that wont mean creating a entire new question I would love to hear it. For clarification, I tool over the project the original poster asked the question about. I managed to delve deeper into the issue and basicly managed to pinpoint better where the issue resides. Thats why I do not view this as a new question. – Patrick Kersten Feb 09 '18 at 08:54