GSoC status report 2

The world tried to stop me, but I pushed through and got some work done on wlroots.

# Hurdles

Unfortunately aside from programming I have a physical form that I have to take care of. Recently this form's hands have been hurting because of strain from typing, which is pretty rude of them, so I took some time out to build a keyboard. Woe is me, having to spend my time soldering and cutting. I had a great time. After finishing the keyboard, all of a sudden it was time to move out, so we packed and shuffled and drove and unpacked and complained about the trains in this country. Then I slept, and yesterday I finally found the time to get back to work. This is why there was no update last week.

# Progress

I've decided that I need consistent terms for the subtasks I have. So: measurement is reading how long a frame takes to render, prediction is coming up with a number of milliseconds, and scheduling is delaying by that number and all the API funk therein. It turns out that Simon was right and there is a lot of API funk for me to deal with. We've had some discussions about what exactly wlr_output.events.frame is for and whether we really need it, and I've implemented a scheduling mechanism based on that signal to show how we can make good use of it.

Bringing together this scheduling, the timer from the first status report for measurement, and some naive prediction (next frame takes at most 1ms more than last frame) christens tinywl as the first user of all this mess. Here are some screenshots from GPUVis showing the old, boring timeline where we rendered immediately after the last present, and the new, sexy timeline where we render immediately before the next one! The purple lines are vblanks, and the boxes in each row represent durations when those processes were running on the CPU. I think blue lines are GPU submissions, but the naming is unclear.

Wow, isn't that beautiful.