Memory leak when moving dialog box.

[ZhilinRodion]

Hello,

We started to use AIR SDK 51.2.1.5 for Windows and see performance degradation and memory leaking that after using our app for some time causes the following error: "Out of Virtual Memory : Your system is low on virtual memory. To ensure that Windows runs properly, increase the size of your virtual memory paging file."

We created a sample application that demonstrates the issue. You can download it from here: Test.zip.

See the following video that demonstrates how panning even small popup leads to increasing Private Bytes of the application and to unexpected increasing of consumed system memory:

The bug is not reproduced in 51.1.3.10 version and we guess that this somehow relates to changes in rendering that have been made in 52. We figured that if change renderMode to “gpu” from default “auto”, the issue is no longer reproduced.

Could you please clarify what can be wrong and why behavior of “auto” rendering mode has changed? We also noticed that there is new option useAngle that relies on angle library installed in the system. What is the default value for it? We want to have some stable behavior that doesn’t rely on something that can be missing on customer’s machine.

Regards, Rodion Zhilin, Software Technologies LLC

[ajwfrost]

Thank you for this! We'd had another customer mention a large memory usage when opening new windows and I think that's related to this, having seen what's going on here. The issue was introduced when we added support in Windows for rendering text via DirectDraw, which is needed in order to support coloured emoji characters etc. But there were a couple of issues in the implementation which was causing a significant memory leak.

Interestingly, stripping this back and testing different elements in isolation, there does appear to still be a memory leak if we do a "BeginDraw"/"EndDraw" set of calls - which shouldn't be the case! but there are reports of this online too, it sounds like it may be driver-dependent... we've moved those calls behind some other checks so that none of that happens if you don't need it i.e. unless you have emoji characters, it will rendering using the previous GDI calls.

So for the vast majority of applications/behaviours, we can get a fix for this into the next release...

In terms of the render mode, the new DirectDraw font rendering doesn't work in hardware-accelerated modes because there's a different rendering mechanism internally that's used for those cases! So that's why the behaviour is different in those cases.

Regarding ANGLE - default is to not use that, and actually it's not so mature at the moment so we recommend not including that. The plan though is to use ANGLE by default but to have this distributed along with the AIR DLLs so that it's not going to be missing from the customer machine. Then all rendering from our perspective will use OpenGL ES, and ANGLE will translate that into Direct3D/Metal/Vulkan/OpenGL/etc. We'll still have the "cpu" mode if people need it, but for the hardware-accelerated options, it will consolidate via ANGLE (in the same way that Chrome, Firefox etc work..)

thanks

[vitalysoftech]

Thanks, @ajwfrost !

When we select "auto" for renderingMode and see the issue, does it mean that AIR automatically selects "cpu" in the case? I wonder, what the criteria is.

Regards, Vitaly Shlyaga Software Technologies LLC

[ajwfrost]

The logic around the rendering mode involves setting up a list of modes and seeing whether we can set them up:

• if you opted for 'gpu', this is added to the list first
• if you opted for 'direct', this is added to the list next
• if you used 'auto' but it's a full-screen app, then 'direct' is added to the list (in most cases, there are some conditions..)
• finally, 'cpu' is added

So normally "auto" == "cpu" but there are sometimes some platform-specific handling based on settings/configurations.

[vitalysoftech]

Is it safe to use "gpu"? Will it fallback to "cpu" if something on hardware level is not supported?

[ajwfrost]

GPU has a few differences in the features supported (particularly around filters/blending) plus in some cases it's not actually very well accelerated. If you're looking for a short-term fix for this, can you use "direct" mode? This renders the content using CPU but composition happens in the GPU and is the generally recommended option to use..

Editing to actually answer your question: no it does not fall back, other than a few checks at start-up for some older graphics cards/settings that might be unsupported where Adobe had found particular issues in the past. But it has no real auto-detection of failures or any fail-over mechanism...

thanks

[vitalysoftech]

We would like to wait for the fix from your side to be safe. I asked because I wondered, looking closer now to the modes, whether we use the most optimal one (we use "auto").

BTW, does "direct" use the same approach to drawing texts like describe above? AFAIU, using the mode then will lead to memory leaks as well.

[ajwfrost]

We kicked off a release last night so it hopefully will be out on Monday...

Direct mode actually has a slight difference when rendering text as it uses an intermediate surface to then composite .. hence this would avoid the memory leak. Alternatively you can also delete the "DDrawFontSupport.dll" file, without this it will always fall back to the earlier mechanism, regardless of the render mode.

thanks

[vitalysoftech]

Thanks, Andrew! We are looking forward.