MultiSurfaceActivity bouncing ball freeze

[gurtajs4]

Hi,

I am running grafika MultiSurfaceActivity and Record GL on Andriod Lollipop 5.1 running on Freescale Sabre SD board.

I can see all the test play smoothly when no screen is touched or disturbed, but as soon as I start scrolling the notification bar from top and continue that for long time, the fps gets reduced to 35-40FPS.

I have confirmed the same test on Kitkat 4.4.2 and JB 4.2.2 and they seems to work fine.

So behaviour when playing MP4 from Gallery. The video gets stuck and lags a lot when we start playing with Notification bar

Can you share your though on this. I also had to change BufferQueue implementation to ASync mode to achieve over 60FPS.

Regards,
Gurtaj

[fadden]

The bouncing ball is software-rendered, so anything that soaks up CPU time is going to make it slow down. On devices with medium-grade CPUs and big displays (e.g. Nexus 10) it never gets close to 60fps. So a slowdown while you are playing with the nav bar doesn't surprise me, but if it continues to be slow even after you stop playing with the nav bar, then that's a little weird.

Video playback should be less affected, as that does less with the CPU.

Investigation into such problems usually begins by using systrace to capture traces in "good" and "bad" states, and comparing the two.

The key point of BufferQueue "async mode" is to allow frames to drop if the consumer can't keep up with the producer. It's primarily meant for SurfaceTexture, where producer and consumer are in the same app, potentially on the same thread, so having the producer stall waiting for the consumer could cause the program to hang. I'm not sure what you mean by needing it to exceed 60fps, but I would guess you're throwing frames at the display faster than it can render them... so you're not really increasing the frame rate, you're just using the BufferQueue to drop the frames instead of using Choreographer to decide when you need to drop them yourself.

In any event, I left Google back in June 2014, well before Lollipop was completed. If something works correctly on KitKat but weirdly on Lollipop, I'm afraid I can't provide much insight. If you can reproduce the behavior easily, it might be worth capturing a video that demonstrates the problem (point a second smart phone at the device exhibiting the problem, so they can see how you manipulate the device) and filing a bug on http://b.android.com/.

[gurtajs4]

Hi Sir,

Thank a lots for replying back.I have learned a lots from your comments and android posts.I really admire you for what you are its a great opportunity to have some discussion with you.

I am new with systrace and did some analysis with dumpsys SurfaceFlinger, and I am trying to analyse the performance with video playback on Kitkat and Lollipop while palying around with nav, I see BufferQueue logs with one buffer free and rest two in acquired and dequeued state in Lollipop but in Kitkat two of them are free and one is acquired.

Its always been same for KitKat, no matter the CPU usage is High and Video playback is smooth with 60FPS. Can it be VSync or Triple buffering issue? I have access to the whole android source code, which can be build and compiled. Do you have any suggestion for me to change something in framework/native/libs/gui or surfaceflinger code and find a root-cause or workaround?

[LP]
-BufferQueue mMaxAcquiredBufferCount=1, mDequeueBufferCannotBlock=0, default-size=[1024x720], default-format=1, transform-hint=00, FIFO(0)={}
[00:0xac892100] state=FREE , 0xb6086d00 [1024x 720:1024, 1]
>[01:0xb5c42280] state=ACQUIRED, 0xb6086c40 [1024x 720:1024, 1]
[02:0xac891a00] state=DEQUEUED, 0xb6085c80 [1024x 720:1024, 1

[KK]
-BufferQueue maxBufferCount=3, mSynchronousMode=1, default-size=[1024x720], default-format=1, transform-hint=00, FIFO(0)={}
[00] state=FREE , crop=[0,0,0,0], xform=0x00, time=0x48f5282d5f8, scale=FREEZE, 0x400f6a88 [1024x 720:1024, 1]
>[01] state=ACQUIRED, crop=[0,0,0,0], xform=0x00, time=0x48f57e7f313, scale=FREEZE, 0x40763f20 [1024x 720:1024, 1]
[02] state=FREE , crop=[0,0,-1,-1], xform=0x00, time=0, scale=FREEZ

[fadden]

Debugging with dumpsys SurfaceFlinger can be tricky because it just grabs a snapshot of one instant in time. systrace grabs the entire stream of events, and shows the relationships between events, so you can establish cause and effect. Unfortunately, it's also a lot harder to decipher.

There's a few notes about watching BufferQueue behavior in systrace output at the end of the graphics arch doc. By watching the appropriate row you can tell if your SurfaceView's Surface is starving or being inundated. (In async mode it'll be less interesting, since it doesn't let the buffers queue up.) The "scheduled swap" Activity is fun to watch in systrace on KitKat+ with different patterns selected... the grafika README even shows the recommended systrace capture command for that Activity.

There are a lot of moving parts and different stages as stuff moves through the system, so it's difficult to guess at what the problem would be. A great many problems received by the graphics team were resolved by capturing a trace and staring at it... it's the only way to see events over time and across processes.

[gurtajs4]

Hi Sir,

I have captured the systrace logs in good and bad state attached.
One problem I see in systrace is that it does not show SurfaceFlinger process and FRAMES in dump, as it used to in Kitkat version.

What could be the reason for that?

Also from the lollipop systrace output in good state and bad state, I see the RenderThread kikking in a thus my process ple.myyuvviewer slows down. Also priority of RenderThread is greater than my process. So is there a way to reduce RenderThread Priority ?

https://www.dropbox.com/s/luwovq7ohozccdy/Lollipop_bad.zip?dl=0
https://www.dropbox.com/s/zkv0aqw0shecpw2/lollipop_good.zip?dl=0

https://www.dropbox.com/s/g7qe01xvmfyvpak/kitkat.zip?dl=0

Regards,
Gurtaj

[fadden]

As this isn't really an issue with Grafika, I've added remarks to the stackoverflow question you opened instead. We should continue there as it has better visibility for others with similar issues.