Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What are the technical, underlying reasons behind Robot().createScreenCapture() being so slow?

Tags:

java

I've been trying to build a screen recorder to practice my atrophied Java skills (even though there are already way too many).

However, I've come upon the problem of the Robot class being ridiculously slow -- around maybe 15fps even on my i7 powered machine, and a crawling 4-5fps on my macbook. I've built a working recorder with Python and was able to at least reach a reliable 20-24fps by grabbing snapshots with PIL.

So, I'm curious, what is the technical reason for the class being so slow?

Further, how do other screen recorders work? Screencast-o-matic is Java, and seems to perform well. I assume that there is some way of connecting with the underlying OS, and ripping everything out of a buffer or something? I image that there has to be some ridiculously fast way to get copies of what's being drawn on the screen -- After all, the OS is fast enough to draw the screen multiple times after all while doing a kajillion other calculations! It seems copying an array of colors from one place to another should be a relatively cheap operation.

I'm determined not to give up! I just don't know what I need to know to really dive into the meat of building a proper recorder.

like image 389
Zack Avatar asked Nov 13 '22 12:11

Zack


1 Answers

I'm not totaly sure. but is still a very likely reason.

operating system: the operating system already paints the screen. it makes sens that, it has the Graphic stored until there happense something new. a graphic can easly be saved.

java Robot: the robot collects the data before it can store it. the screen capture uses Method. the Method is getPixelColor(). it makes a big loop to get all the pixels on the screen. on a HD-screen the method is called 921600 times(1280*720), this takes time plus it needs to be compressed to a image and saved.

like image 52
Ole van Santen Avatar answered Nov 15 '22 05:11

Ole van Santen