Hi,
it looks like there is a CPU-Use issue in this function.
But i think a sample is even more helpfull to reproduce:
var device = AdbClient.Instance.GetDevices().First();
while (true)
{
var img = AdbClient.Instance.GetFrameBufferAsync(device, CancellationToken.None).Result;
Thread.Sleep(100);
}
The CPU-Use from adb.exe is only 0-2%. But the GetFrameBufferAsync-function jumps to 30% (if VS dont lie). Donno what happend here :/
(i know it's a bit like #39 but i truly think the CPU-Use problem is not an adb-problem)
Greetings
EDIT
i think i found the problem. The AdbSocket.Read
use a while loop which some times runs in idle and let the CPU-Use grow. A simple Thread.Sleep(1);
reduce the CPU-Use down to < 10%. A Thread.Sleep(10);
to < 5%.
Maybe there is a more efficient way to check for idle. But i'm relative sure that this is the problem.
Before:
![before](https://cloud.githubusercontent.com/assets/15054322/15422805/8837dc24-1e7a-11e6-98d8-e73a41a888a4.png)
(Sry for the german image)
After (1ms delay):
![after_1ms](https://cloud.githubusercontent.com/assets/15054322/15422817/966014f6-1e7a-11e6-935d-c3a64feea3ef.png)
(Sry for the german image)
EDIT2
Btw. GetFrameBufferAsync
could also use AdbSocket.ReadAsync
instand of the sync version. But the AdbSocket.ReadAsync
is also missing the Thread.Sleep(1);
or somthing more efficient^^
EDIT3
It does not even make a big different in result (run time of the function) if use Sleep(1) or Sleep(10). But CPU-Use also drops again 50%. So for me 10ms would be perfect.
But it would be perfect if the socked it self would block until there are no data to Receive.
EDIT4
Btw. an optimum would be if madb could deliver a stream of this:
http://stackoverflow.com/questions/26786926/android-screen-capture
I try it in ABD and its very very very fast.