fix mjpegstream logic for returning screenshots #1039
Conversation
|
Screenshots in general, or streamed screenshots? |
|
I guess this kinda makes sense, since the built-in mjpeg streamer is itself a consumer of device screenshots, and uses them to build the stream. To get a performance improvement, we'd have to use an mjpeg server that was faster at getting screen images than WDA's screenshot method. This is definitely the case on Android, where ADB's screenshotter is super slow compared to other methods, and there are mjpeg implementations for Android which are extremely fast. What could a faster method be on iOS? Presumably getting the video stream directly from Apple's own video out, or maybe reading from a vnc session sized to fit exactly over the simulator window? I imagine cloud services have ways outside of Appium to get real time video, which could also lead to an mjpeg stream if they wanted. |
| @@ -17,7 +17,8 @@ commands.getScreenshot = async function getScreenshot () { | |||
| }; | |||
|
|
|||
| // if we've specified an mjpeg server, use that | |||
| if (this.mjpegStrem) { | |||
| if (this.mjpegStream) { | |||
There was a problem hiding this comment.
this is a bug that would not have been possible in some other languages :-/ i'm guessing it's my typo!
So, a typo here prevented screenshots from being returned from the mjpegstream.
Here's something interesting though, fixing this caused screenshots on my machine to go from taking ~172ms each to taking ~436ms. So by fixing this, screenshots are actually less performant on iOS.