Low frame rate during debugging

[Asahi-Gaby]

Problem Description

We’re a Chinese company which make mobile games.

Around May or June, we found some computers running at a low frame rate when debugging with Flash Builder 4.7.

• Which AIR SDK did you use? AIR SDK 3.4 / 33.1.1.217 / 33.1.1.554
• Describe the affected environment: Windows 10 Pro
• Can you reproduce it yourself, or did you get reports from other users? If so, how many users are affected (percentage)? Yes. Issue steadily occurs on 4 of 10 our machines. The others work well.

We’ve written an empty 60 fps project demo(see attachment). Here’s the test report:

1. Made sure there’s no break points.

2. Change AIR SDK: The issue occurs from the oldest to the newest.

3. Running Flash Builder in win7 compatibility mode: Invalid.

4. Reinstall Flash Builder: Invalid.

5. Use “Run” instead of “Debug”: Works! Demo ran in 60fps.

6. Debugged with Flash Builder, and then disconnected with ADL: Works!

7. Debugged with Intellij Idea: Invalid. Performed same as Flash Builder.

8. Run ADL alone via console: Works!

9. Run FDB first, then ADL. Invalid. ADL played at a low frame rate, but resumed 60 fps after FDB closed.

10. Listening the net traffic with Wire Shark, found there wasn’t any socket communication between FDB and ADL after connecting.

11. Copied the demo to 10 computers(configuration in the attachment). 4 of 10 were slow whereas others worked well.

12. Analyzed with Adobe Scout and Windows Task Manager. The CPU usage of this project was low, but the “other” overhead was high. Multi-core:

13. Manually set Flash Builder、ADL、FDB run with single CPU core. Still low CPU usage, but the issue eased a little? Single-core:

14. Reinstalled Windows, Re-downloaded newest AIR SDK, debug with FDB and ADL, to make sure nothing was cached. Invalid, still low frame rate.

15. Accidentally, we build the demo with advanced-telemetry, and debugged with Flash Builder and Adobe Scout , “Action Script Inspector” checked. Things worked well!

16. We knew how the Scout works, therefore, we tried flash.sampler.startSampling() in the demo. The demo was in 60-fps! But return to slow as soon as stopSampling() called.

Sorry but, the issue occurs only on 4 of 10 our computers . We couldn’t find the characteristics of the computer that can reproduce the issue. Can you please determine if this is a bug with ADL? We have tried many possible solutions but none seem to have worked perfectly.

Currently, we swap computers for debugging. Please have a look on the issue. Waiting for your reply. Thanks!

The step to run a test project:

1.Run Adobe Scout to observe performance. Make sure “Action Script Inspector” UNCHECKED. 2.run startFDB.bat and input "run" 3.run startADL.bat 4.input cmd "c"(continue) at FDB console

Flash Air Test Project.zip

[Asahi-Gaby]

We reinstalled older version of Windows, the number of frames returned to 60. But we still don't know what caused this issue. This windows version is Windows 10 1903.

[itlancer]

May be related issues: https://github.com/airsdk/Adobe-Runtime-Support/issues/85 https://github.com/airsdk/Adobe-Runtime-Support/issues/307

[Asahi-Gaby]

May be related issues:

85

307

Thank you for your reply, but I think the issues are not the same.

[itlancer]

I have the same issue using Adobe Animate even with "empty" AIR application, especially using 60 FPS. But with VS Code it works fine. Tested with latest AIR SDK 33.1.1.713.

[itlancer]

Issue still exists with latest AIR SDK 50.1.1.2. It happens sometimes (not 100% reproducible) but only using debugger. Tested with Adobe Animate 22.0.8 for Windows 10 Pro. Almost always it can be reproducible if you turn your device in power saving mode (but it still powerful enough) and using this code sample:

package {
    import flash.display.Sprite;
    import flash.events.Event;
    import flash.system.Worker;
    import flash.system.WorkerDomain;

    public class WorkerBug extends Sprite {

        public function WorkerBug() {
            if (Worker.current.isPrimordial) {
                addEventListener(Event.ADDED_TO_STAGE, init);
            } else {
                trace("worker");
            }
        }

        private function init(e:Event):void {
            removeEventListener(Event.ADDED_TO_STAGE, init);
            stage.frameRate = 60.0;
            var worker:Worker = WorkerDomain.current.createWorker(this.loaderInfo.bytes, true);
            worker.start();
        }
    }
}

You will see in Scout:

3 seconds after debugger start all frame time will be consumed by "Runtime overhead" and FPS drops from 60 to ~30.