evansste wrote: So the bottleneck probably has more to do with working thorough the GUI, in general (opening new windows, and that sort of thing).
I reckon you are on the right track here in the sense that you are thinking about the possible causes from an OS level.
GUI rendering has a high overhead in many systems and one common trick is to disable rendering until all the GUI elements have been
created in the screen buffer. Screenshots not only read the screen contents but also convert the data into a bitmap & (possibly) write to disk.
If you really want to spend time on this issue, I would suggest the approach I described in a previous forum entry.
Surround the critical code segments with timestamp code & gather some hard data:
- Do the screenshots always take the same amount of time or do they get slower over time?
- Does changing the resolution actually affect the speed of the screenshots?
- Can you speed up the screenshots by disabling/enabling rendering?
- Can you speed up the screenshots by terminating unncessary Daemons & processes in your Raspi linux environment
- Can you use any other different methods for taking the screenshots
- I'm only guessing but I assume you are using an Octave function for screenshots.
- Directly calling a Raspi linux screenshot function might be faster...
- You might also be able to directly read the screen buffer, store each copy in a pre-allocated array in memory
and then render all the array elements to bitmaps & save them to disk at the end of the program.
My main point is that there are many different ways of speeding things up and having hard data on the actual
speeds resulting from each idea will be a real help....
Keep up posted on your progress!