search

airsdk / Adobe-Runtime-Support

Report, track and discuss issues in Adobe AIR. Monitored by Adobe - and HARMAN - and maintained by the AIR community.
200 stars 11 forks source link

Input dispatching timed out callTimeoutFunction #448

Open ghost opened 4 years ago

ghost commented 4 years ago

Hello Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago. Wait queue length: 2. Wait queue head age: 6703.6ms.)

AIR_SDK 31.1.1.217

`"main" prio=5 tid=1 Native | group="main" sCount=1 dsCount=0 flags=1 obj=0x750abae0 self=0x74b8414c00 | sysTid=10523 nice=-10 cgrp=default sched=0/0 handle=0x753f94f548 | state=R schedstat=( 50989523734 1330095751 13551 ) utm=4475 stm=623 core=0 HZ=100 | stack=0x7fd6e6a000-0x7fd6e6c000 stackSize=8MB | held mutexes=

00 pc 00000000008e1f70 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

01 pc 00000000008d2a84 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

02 pc 00000000008df150 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

03 pc 00000000008cf1bc /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

04 pc 000000000026ffac /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

05 pc 0000000000270c50 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

06 pc 0000000000408880 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

07 pc 0000000000407e70 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

08 pc 0000000000407d88 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

09 pc 0000000000409b70 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

10 pc 000000000040348c /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

11 pc 0000000000404d30 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

12 pc 0000000000319468 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

13 pc 000000000042de00 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

14 pc 0000000000437d94 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

15 pc 00000000003c77d8 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

16 pc 00000000003c7de8 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

17 pc 00000000004361b0 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

18 pc 0000000000437b6c /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

19 pc 00000000004363f0 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

20 pc 0000000000437b6c /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

21 pc 00000000004363f0 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

22 pc 0000000000437b6c /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

23 pc 00000000004363f0 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

24 pc 000000000040e208 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

25 pc 000000000040f8ac /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

26 pc 00000000003607b4 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

27 pc 00000000003613b4 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

28 pc 00000000003612d0 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

29 pc 000000000035d554 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

30 pc 000000000048c430 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

31 pc 00000000004af33c /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

32 pc 00000000004aff24 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

33 pc 000000000025efd8 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

34 pc 000000000026231c /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

35 pc 0000000000265c10 /data/app/com.*.fe-XMzuZTvxtLF4Mbe0CN2wyA==/lib/arm64/libCore.so (???)

at com.adobe.air.customHandler.callTimeoutFunction (Native method) at com.adobe.air.customHandler.handleMessage (customHandler.java:22) at android.os.Handler.dispatchMessage (Handler.java:106) at android.os.Looper.loop (Looper.java:224) at android.app.ActivityThread.main (ActivityThread.java:7081) at java.lang.reflect.Method.invoke (Native method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:536) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:928)`

image

ajwfrost commented 4 years ago

We'd just been looking at this and thinking it was a crash log .. the top of that call stack is when it's decompressing a JPEG image, and it does seem a little odd that we allocate a buffer using 'output_components' but within libjpeg it's using 'num_components'..

Anyway: if this is an ANR, then the activity going on here is the software rendering and decoding of JPEG images. Decoding can take a while perhaps especially if there are multiple large images that all need to be handled at once (i.e. rendered for the first time all together in one frame), and if memory management then kicks in with a 'sweep' phase it may push this operation out beyond 5s.

Asynchronous decoding of images would be nice to use but would break the paradigm a little in terms of what developers expect.. maybe we could have a new API for adding in images where decoding happens outside of the main thread and we dispatch events when they are ready? would be interested in your thoughts.

To try to migitate this, is it possible to add images onto the stage one frame at a time, or similar? i.e. frame 1 = add first image, frame 2 = add second image.. you can always keep things under a main sprite which is kept invisible until it's all ready to render..

thanks

ghost commented 4 years ago

Is it only for jpeg downloads? or png too? Embed png?

Gokulv617 commented 3 years ago

We'd just been looking at this and thinking it was a crash log .. the top of that call stack is when it's decompressing a JPEG image, and it does seem a little odd that we allocate a buffer using 'output_components' but within libjpeg it's using 'num_components'..

Anyway: if this is an ANR, then the activity going on here is the software rendering and decoding of JPEG images. Decoding can take a while perhaps especially if there are multiple large images that all need to be handled at once (i.e. rendered for the first time all together in one frame), and if memory management then kicks in with a 'sweep' phase it may push this operation out beyond 5s.

Asynchronous decoding of images would be nice to use but would break the paradigm a little in terms of what developers expect.. maybe we could have a new API for adding in images where decoding happens outside of the main thread and we dispatch events when they are ready? would be interested in your thoughts.

To try to migitate this, is it possible to add images onto the stage one frame at a time, or similar? i.e. frame 1 = add first image, frame 2 = add second image.. you can always keep things under a main sprite which is kept invisible until it's all ready to render..

thanks

I tried this. but there is not much reduce in ANR's. It is increasing everyday. Do have any other solution ?