I have some big memory issues in an angular/typescript app using the forge viewer (v6.6.1). This has also been discussed before: Severe memory leaks in the Autodesk Forge viewer on devices
Whenever we close the component or route to an other page we destroy the current created viewer. For this I use the function viewer.finish(); However it seems that it doesn't release any GPU memory. This is most notable when using models that contain textures. The problem is that after a few times opening this in our app it will crash as to much gpu memory is used.
To see the memory usage buildup I used chrome://tracing/ (using the record category memory-infra).
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
As you can see the memory under textures builds up quite fast. And this is just a light model that we use. With some models is build up in steps of over 250MB.
Here is the part of component code that does the work. I also provided a link to a minimal angular project on github that you can run. When you start the app you can use the toggle button to create / destroy the component and trigger the issue.
public viewer;
public options;
public url = 'MODEL-YOUR-URL-HERE';
#ViewChild('viewer')
public viewerContainer: any;
constructor() { }
ngOnInit() {
this.options = {
env: 'Local',
useADP: false,
language: 'en',
};
Autodesk.Viewing.Initializer(this.options, () => {
this.onEnvInitialized();
});
}
public onEnvInitialized() {
this.viewer = new Autodesk.Viewing.Private.GuiViewer3D(this.viewerContainer.nativeElement, {});
this.viewer.initialize();
this.viewer.loadModel( decodeURI(this.url), {}, () => { }, (aErrorCode) => { } );
}
ngOnDestroy() {
this.viewer.finish();
this.viewer = null;
}
https://github.com/zedero/forge-angular-memory-issue
Engineering's final recommendations are to wait for Viewer v7.0 which is set to release for general access in a few weeks time with multiple bug fixes & improvements on memory management.
In the meantime see if you have any event listeners/custom extensions that might be holding on to references to nodes etc - remove/unload these and see if that helps.
Related
In our project, we use AudioContext to wire up input from a microphone to an AudioWorkletProcessor and out to a MediaStream. Ultimately, this is sent to other peers in a WebRTC call.
If someone loads the page, the audio always sounds fine. But if they connect with a hard-wired microphone like a laptop mic or webcam, then connect a bluetooth device (such as airpods or headphones), then the audio becomes distorted & robotic sounding.
If we tear out all the other code and simplify it, we still have the issue.
bypassProcessor.js
// Basic processor that wires input to output without transforming the data
// https://github.com/GoogleChromeLabs/web-audio-samples/blob/main/audio-worklet/basic/hello-audio-worklet/bypass-processor.js
class BypassProcessor extends AudioWorkletProcessor {
process(inputs, outputs) {
const input = inputs[0];
const output = outputs[0];
for (let channel = 0; channel < output.length; ++channel) {
output[channel].set(input[channel]);
}
return true;
}
}
registerProcessor('bypass-processor', BypassProcessor);
main.js
const microphoneStream = await navigator.mediaDevices.getUserMedia({
audio: true, // have also tried { channelCount: 1 } and { channelCount: { exact: 1 } }
video: false
})
const audioCtx = new AudioContext()
const inputNode = audioCtx.createMediaStreamSource(microphoneStream)
await audioCtx.audioWorklet.addModule('worklet/bypassProcessor.js')
const processorNode = new AudioWorkletNode(audioCtx, 'bypass-processor')
inputNode.connect(processorNode).connect(audioCtx.destination)
Interestingly, I have found if you comment out the 2 audio worklet lines and instead create a simple gain node, then it works fine.
// await audioCtx.audioWorklet.addModule('worklet/bypassProcessor.js')
// const processorNode = new AudioWorkletNode(audioCtx, 'bypass-processor')
const gainNode = audioCtx.createGain()
Also if you simply create the AudioWorkletNode, but don't even connect it to the others, this also reproduces the issue.
I've created a small React app here that reproduces the problem: https://github.com/JacobMuchow/audio_distortion_repro/tree/master
I've tried some options such as detecting when this happens using 'ondevicechange' event, closing the old AudioContext & nodes and recreating everything, but this only works some of the time. If I wait for some time and then recreate it again, it works so I'm worried about some type of garbage collection issue with the processor when attempting this, but that might be beside the point.
I suspect this has something to do with sample rates... when the AudioContext is correctly recreated it switches from 48 kHz to 16 kHz and then it sounds find. But sometimes it is recreated with 48 kHz still and it continues to sound robotic.
Threads on the internet concerning this are incredibly sparse and I'm hoping someone has specific experience with this issue or this API and can point out what I need to do differently.
For Chrome, the problem is very likely https://crbug.com/1090441 that was recently fixed. I think Firefox doesn't have this problem but I didn't check.
"Autodesk.Viewing.OBJECT_TREE_CREATED_EVENT" was working with viewer version 6, but when I upgrade viewer version to 7.*, its not working.
I have tried to handle "Autodesk.Viewing.GEOMETRY_LOADED_EVENT", and then call the model.getObjectTree() function, but I get the following error
{instanceTree: null, maxTreeDepth: 0, err: undefined}
How can I handle the object_tree_created event for viewer 7 in my code?
Obviously the model database (which contains object tree data) failed to load (and hence the object tree event was not fired and the object tree was not accessible) and it could have been for incorrect code or networking. Did you get other errors especially network interruptions in your browser's dev tools when loading the model? What is your code to load the model? If loading from Forge did you follow the migration guide and here to use loadDocumentNode?
Autodesk.Viewing.Initializer({ env: 'AutodeskProduction', getAccessToken}, () => {
const viewer = new Autodesk.Viewing.GuiViewer3D(container);
Autodesk.Viewing.Document.load(urn, viewerDocument =>{
var defaultModel = viewerDocument.getRoot().getDefaultGeometry();
viewer.loadDocumentNode(viewerDocument, defaultModel);
I am trying to use MassTransit for Request/Response communication through Azure service bus queue. Sender is an Azure WebApp, Consumer is a windows service installed at on-premise machine.
Everything works fine when it is about small volumes of messages. However as soon as I start sending more than ~20 msg/sec i see severe(1-2 sec) delays in responses from consumer. My telemetry tells me that delay is happening at point when consumer needs to grab messages from queue.
One strange, but I think important part of behavior: I can see that with current load amount of unread messages in queue is on avg constant and its 25. If I send 2x more messages, than I see on avg 50messages in queue. With delays on consumption side i would expect queue to GROW, but it is constant, so it is definitely something inside code that throttles the connection.
Quick info:
There are no problems with hardware on the machine. CPU/Mem not high.
I tried playing with the UseConcurrencyLimit, MaxConcurrentCalls, PrefetchCount configs on consuner side. It did not help
My solution code of sender and consumer are next to classic examples.
Consumer: .Net framework 4.7.2 and MassTransit.Azure.ServiceBus.Core 5.5.2
Here's my listener class with all business logic removed:
public class QueueListener
{
private IBusControl Bus { get; set; }
public QueueListener()
{
Bus = MassTransit.Bus.Factory.CreateUsingAzureServiceBus(serviceBusFactoryConfigurator =>
{
var host = serviceBusFactoryConfigurator.Host(SettingsHelper.AzureServiceBusConnectionString,
(config) =>
{
config.OperationTimeout = TimeSpan.FromSeconds(60);
config.TransportType = TransportType.AmqpWebSockets;
});
serviceBusFactoryConfigurator.ReceiveEndpoint(host, SettingsHelper.CouponQueryQueueName, e =>
{
e.Handler<JToken>(HandleMessage);
e.UseConcurrencyLimit(16);
e.MaxConcurrentCalls = 16;
e.PrefetchCount = 32;
});
serviceBusFactoryConfigurator.EnableBatchedOperations = true;
serviceBusFactoryConfigurator.DefaultMessageTimeToLive = TimeSpan.FromSeconds(60);
});
}
private async Task HandleMessage(ConsumeContext context)
{
await Task.Delay(800);
if (context.ExpirationTime > SystemDateTime.Now)
{
await context.RespondAsync(new CouponUsedList { CouponsUsed = new List<CouponCurrentUsed>() });
}
}
public Task LaunchAsync()
{
return Bus.StartAsync();
}
public Task StopAsync()
{
return Bus.StopAsync();
}
}
Seems that here, once again, it was just missing one config. All code that you write inside ReceiveEndpoint configurates the consumer listener queue and configurations that you provide in CreateUsingAzureServiceBus are configurations for a consumer response queue.
All I needed was to add one line inside consumer configuration. Without this config all prefetched messages are handled gradually
e.EnableBatchedOperations = true;
I upgraded the forge viewer version of my solution to 6.* to utilize the latest released feature "Document browser extension" as it mentions here
This extension doesn't appear for me, please help.
I got it to work after some experimenting.
Here is my workflow in case you still need it.
First, initialize the viewer:
// initialize the viewer
Autodesk.Viewing.Initializer(adOptions, () => {
// when initialized, call loading function
this.loadDocument(encodedUrn);
});
Then, load your document in the function called above:
// load the document from the urn
Autodesk.Viewing.Document.load(
encodedUrn,
this.onDocumentLoadSuccess,
this.onDocumentLoadFailure,
);
In the success callback you can now do the following:
onDocumentLoadSuccess(doc) {
// get the geometries of the document
const geometries = doc.getRoot().search({ type: 'geometry' });
// Choose any of the available geometries
const initGeom = geometries[0];
// and prepare config for the viewer application
const config = {
extensions: ['Autodesk.DocumentBrowser'],
};
// create the viewer application and bind the reference of the viewerContainer to 'this.viewer'
this.viewer = new Autodesk.Viewing.Private.GuiViewer3D(
this.viewerContainer,
config,
);
// start the viewer
this.viewer.start();
// load a node in the fetched document
this.viewer.loadDocumentNode(doc.getRoot().lmvDocument, initGeom);
}
I hope this will make it work for you as well. What helped me was the reference to the loadDocumentNode function in this blog post.
I have some problems with thread synchronization in my Templated control (trying to do a AutoComplete control)
Inside my control I have this code:
protected override void OnApplyTemplate()
{
base.OnApplyTemplate();
var searchTextBox = GetTemplateChild("SearchTextBox") as TextBox;
if (searchTextBox != null)
{
var searchDelegate = SearchAsync;
Observable.FromEventPattern(searchTextBox, "TextChanged")
.Select(keyup => searchTextBox.Text)
.Where(TextIsLongEnough)
.Throttle(TimeSpan.FromMilliseconds(500))
.Do(ShowProgressBar)
.SelectMany(searchDelegate)
.ObserveOn(Dispatcher)
.Subscribe(async results => await RunOnDispatcher(() =>
{
IsInProgress = false;
SearchResults.Clear();
foreach (var result in results)
{
SearchResults.Add(result);
}
}));
}
}
And it is complaining that inside my ShowProgressBar method I'm trying to access code that was marshalled by another thread.
If I comment out the Throttle and the ObserveOn(Dispatcher) it works just fine, but it does not throttle my service calls as I want to.
If I only comment out the Throttle part, Nothing happens at all.
Asti's got the right idea, but a far better approach would be to provide the IScheduler argument to Throttle instead:
// NB: Too lazy to look up real name
.Throttle(TimeSpan.FromMilliseconds(500), CoreDispatcherScheduler.Instance)
This will make operations below it happen on the UI thread (including your ShowProgressBar), up until the SelectMany.
Every dependency object requires that any changes to dependency properties be made only on the Dispatcher thread. The Throttle is using a different scheduler, hence making any changes to the UI in a subsequent Do combinator would result in an access exception.
You can resolve this by:
Add an ObserveOnDispatcher before any actions which cause side-effects on the Dispatcher. Optionally use another scheduler down the pipeline.
Use Dispatcher.Invoke to execute side-effects through the dispatcher. E.g., .Do(() => Dispatcher.Invoke(new Action(ShowProgressBar)))