Thu, 17 Aug 2023 00:52
And this is why it's probably very different now since everything runs in it's own process etc. I've made a brief attempt to go through this part, here are the findings.
- All serenity apps work on a client/server architecture and there is always a split with interprocess communication in between
- Qt::WebContentView pokes LibWebviewImplementation which pokes WebContentClient for repaint. This client in turn asynchronously notifies the the other process and the call lands in WebContent::ConnectionFromClient, which registers repaint request and those are processed every so often in the
flush_pending_paint_requests function
- Actual rendering happens with WebContent::PageHost class that uses backing buffer (which I need to understand, it's some interprocess memory sharing mechanism probably). After rendering is done, the other side is pinged back
- We start unwinding -
WebContentClient::did_paint gets called and it calls WebContentView::notify_server_did_paint which replaces the buffer on it's side and poke Qwidget to update and that one finally calls paintEvent which takes the buffer and renders it as a QImage and that's what we see