WebKit wasn’t trying to draw anything to the screen. Turns out, it wasn’t aware that it was visible. No use drawing a web page when you’re invisible, right? Well, I told it that it is visible, and now it’s trying to draw to the screen. Of course, it crashes while trying to do so. It hasn’t tried to draw to the screen in ages. Everything is bit rotted!
Well, it’s very promising !..
…just later show us what you - Webkit with your help - can draw now 
We would also enjoy some nice panorama to sites and Minibrowser - à la native! 
It’s good to see there is progress on the WebKit2 port, although this is probably just too massive for a GSoC project.
We had WebKit 2 rendering things to screen in a past GSoC project, there is no reason we couldn’t do it again. I just hope this time the code will be a bit cleaner and can be merged into the main development branch of WebKit.
While the WebKit codebase is very large, there are not so many parts involved in making a port, and, once you have identified them, it’s actually a rather linear process (fix one bug, hit the next one, fix that, and so on).
Anyway, even if it doesn’t end up with a fully working browser, a lot of progress will be made. That is still a good GSoC project, and maybe Zardshard will continue working on it after GSoC is over, too.
I hope @Zardshard is not feeling completely lost in WebKit sourcecode at the moment 
Alas, I fear that may be true.
Not lost, fortunately. But it seems there are always three good ways to do something. And I have to choose one! grrr…
Easy!
echo $((1 + $RANDOM % 3))
You’re welcome! 
We had WebKit 2 rendering things to screen in a past GSoC project, there is no reason we couldn’t do it again.
Yes, sure, I was referring to the whole WebKit2 stuff. From my point of view it feels so massive that a GSoC it’s probably too short to make huge advances, even though progress is clearly being made.
My dad was a US Marine in the late 1950’s. His job was to run communication cables up a pole or tree as troops hit the ground. His life expectancy in combat was something like 20 seconds! He gets as far as he can with the cables, the next guy gets a little further etc… Until eventually the cables get ran.
Same thing applies here
Keep the code clean, readable and well documented and no work is wasted work
We are a bit more than half-way through, and the problem I’ve been failing to solve since 2019 is already resolved. For me this project is already a success. I can stop banging my head on this specific things that I couldn’t get right, mainly because I could never spare enough time to look into it calmly and solve it properly.
I’m sure by the end of the summer we will have MiniBrowser at least rendering some webpages, and ideally also replying to some keyboard or mouse input. That will not be the end of WebKit2 work for me, sure, but it will still be a major milestone.
Another change has been merged.
As far as I know, we are very close to getting things to display on screen. Render data is being sent from the web process to the UI process (aka MiniBrowser). The UI process is then incorporating it into its own bitmap. As far as I know, all that remains is to draw the bitmap onto the screen! Will it be that simple? We shall see…
Well, I got MiniBrowser to go through all the motions of drawing something on the screen. Here is the result:
Yeah, something somewhere is missing or broken. Time to find it!
Are you sure it’s not just a missing Invalidate() at the end when everything is completed? Without that, app_server may not refresh the screen with the final result. It would be sad to stop just before the very last step!
Wohoo!! Nice screenie! 
Thanks for this 
Alas, it doesn’t help. To take this screenshot, I covered it and uncovered MiniBrowser with another window to get it to update the screen. At least now I know what function to call to fix that.
Nice, we can render about:blank successfully! 
Looks like I’ve found part of the problem.
On the left is a copy of the image WebProcess sent to UIProcess and on the right is the image UIProcess actually received.
BTW, the blue isn’t actually part of a website, just from some testing code. It looks like there will be a bit more work to get WebProcess to send an actual image of a website.
Does WebKit have any regression tests for the IPC system that could maybe help with catching problems like this more easily?
Yeah, WebKit might. I actually have a sparse checkout so I don’t have the tests checked out on the local tree.
Successfully rendered about:blue
So now images are being passed from WebProcess to UIProcess.
What was wrong? Turns out that creating a BBitmap with the flag B_BITMAP_ACCEPTS_VIEWS clears whatever was in the bitmap. That’s why it only displayed white before. I’ve fixed it simply by using that flag less often. I also proposed to make that flag not clear the bitmap in the first place.
Turns out there were no more problems! 
Time to clean up and make the commit!
