GSoC status report 3

API design is kinda tricky.

# Those Who Came Before Me

wlroots is designed to be very very modular. It's clear from the readme:

This design goal seems to have come about from lessons learned in other projects where a more all-in-one approach has become a burden. Note that "pluggable" doesn't just mean you can plug it, it also means that you have to. In my opinion, that's why people shy away from this approach: if you want library users to be able to swap out parts of your code for theirs, you have to force them to be responsible for all the wiring even if they are using the default everything; otherwise they won't have access to the wiring for when they change their mind.

This is all very commendable - engineering has happened, people learned, we are making better tradeoffs now than we were before. But what it means for me is that I have to also learn and do engineering. Imagine! More seriously, I want to respect the consensus that making library users do wiring is good, and they should be able to opt out of my code being called by not calling it.

What I'm finding, though, is that the Thing I'm Trying To Do (scheduling) sounds like a feature but is more of an optimisation. Really, I'm making the frame signal firing be more interesting than it was before. Since the beginning it has worked in its way with a constant delay of zero, and now I am improving it to recognise that the delay might not be zero. I don't think it's possible to do this work in a neat and separate box, because it lies right in the middle of the frame firing path. There's a fair bit of complexity in the way the signal is fired, so refactoring the whole firing path to separate it from what it touches (wlr_output and the backends) is much harder than it might seem.

# The Efforts

Top scientists (me) are working around the clock (or parts of it) to figure out how the scheduling can be decoupled such that it doesn't have to touch the backends at all. And by "working to figure out" I mostly mean "stewing on how it's kind of impossible and I don't think we can do much better than !4214". We'll see, but at the moment it seems like I have to disregard all the pondering from the top of the page and stick my grubby fingers into all kinds of once-sacred functions.

There are measurement woes, too: wlr_scene is a whole thing, and it calls the renderer for you. It spends some time doing that and we need to know how long that time is, so we do need to add measurement code inside the function that does the thing (wlr_scene_output_build_state). I've been doing a lot less pondering and a lot more giving up on this one, and my grand plan at the moment is to just throw a timer right in there and let the user query it. This does make scene bigger, but I think it's alright to expect the code that does the rendering to also do the timing thereof. It will need to be aware of the timer to some extent, so we might as well put the whole thing in there and not bother trying to pretend they're separate.

Aside from all that, I've implemented a timer for the Vulkan backend, but I haven't submitted it yet. Not much more to say there.

Soon, I will have to face prediction and think about statistics. Nooooooo!