Serenity feed

A message by @can3p at Thu, 17 Aug 2023 00:52:43 +0000

2023-08-17T00:52:43Z

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

A message by @can3p at Thu, 17 Aug 2023 00:28:40 +0000

2023-08-17T00:28:40Z

One more interesting bit from the video, here is more or less the snippet:

Core::EventLoop event_loop;

auto qt_event_loop_driver = Core::Timer::create_repeating(50, [&] {
    app->process_events()
})

qt_event_loop_driver->start();

return event_loop->exec()

There are multiple questions one may ask:

Why do we need to run serenity event loop as the main thing and not qt? I'm sure it has it's own timer
How is timer object connected to the event_loop var?

The answer to the second question is simple - there should be a global object somewhere and it's indeed there in form of EventLoopManager class that's implemented as a singleton per system.

So the whole sequence goes as the following:

Timer -> EventReceiver -> EventLoopManager

when an event loop is run it actually calls exec on EventLoopManager so even though it looks like you can have many event loops you actually cannot.

And EventLoopManager does the actual things described in the docs

Getting back to the first question: it was done most probably because the initial implementation had only one process and that was the easiest way to make resource loading work - make qt take a back seat and invoke it only to draw the window every now and then

A message by @can3p at Thu, 17 Aug 2023 00:12:13 +0000

2023-08-17T00:12:13Z

Some hints in the first video on ladybird browser - https://www.youtube.com/watch?v=X38MTKHt3_I

What web engine does is it generates a bitmap given the html it loaded and parsed given the view port dimensions and that's all to it. The rendering engine uses a layout tree that was built during the parsing phase to actually render content in the image.

Now, the rendered content has to be put in the window somehow and that has to be hooked up with QT. That works with Webview class inheriting from QAbstractScrollArea and that one in turn allows to right the behavior for all kinds of nice events including paintEvent which is used to take the bitmap from the engine and render it on the window. How qt does that? No idea, most probably it has it's own render tree for all the widgets and this is where paintEvent stems from. Inside of it Andreas uses QPainter class and that one probably knows how to actually put stuff into graphics memory

A message by @can3p at Wed, 16 Aug 2023 23:05:53 +0000

2023-08-16T23:05:53Z

I'm watching Andreas' hacking session and I'm apparently lacking something essential:

I don't understand how the actual rendering works and that's the most important
I don't understand how events are connected between host operating system and browser itself