I have no guarantees that the disappearing font issue will be fixed. I really want to get it fixed, but honestly nobody is 100% sure on the cause as of right now. The upcoming haikuwebkit-1.8.2 update will address several issues though.
I’m crossing my fingers and bugging everyone daily about it
It may be caused by rectangle clipping. When I investigated WebKit and app_server drawing some time ago, I found that rectangle clipping use special handling and that handling is wrong. As workaround clipping can be rotated to a small angle to use polygon clipping instead of rectangle clipping.
One is region clipping. This can use a BRegion (only rectangles) and always works in screen space (ignoring transforms). This can be used to tell a window that other windows are overlapping, for example, but it is also possible to clip further (GetClippingRegion/ConstrainClippingRegion).
The other is picture based clipping. The idea is more to use a mask that is stored as a BPicture. This can be used not only for clipping, but also for alpha transparency effects if your picture has partially transparent pixels. As a side effect, your clipping shape can be antialiased. This is used in BView ClipToShape, ClipToPicture, and the corresponding “inverse” functions. Picture based clipping works with transforms, so it can be scaled, rotated, etc.
There is a special case in ClipToRect (called from BView::ClipToRect and ClipToInverseRect): https://git.haiku-os.org/haiku/tree/src/servers/app/DrawState.cpp#n474 if no transform is applied, it will optimize the clipping by using the region-based one (which is faster and uses less memory). But if there is a transform, the rect will be transformed, and if there is rotation or shear, it won’t be a rect anymore. So, in that case, shape clipping will be used. However, I don’t see how this can cause a problem, since the fast path with regions is used only when there is no transform at all? What’s missing here?
It would be better than nothing of course but I don’t think reviewers would update their system first thing after a fresh install. It’s the review of the “image” after all, considering they mostly screencast everything from the install to first boot, then finding software to install.
Also, FWIW, let’s not rush the release. I’d like to think people here would also more like something stable than a meet-the-deadline thing.
Nope. If it was a smaller change, I would have immediately reverted. However:
haikuwebkit-1.8.x 's api / abi changed, webpositive had to be rebuilt specially for it.
haikuwebkit-1.7.x is incompatible with haikuwebkit-1.8.x in haikuports
we don’t have a r1/beta3 branch of haikuports
webkit moves fast
Pretty much, none of this has been an easy call. I’m balancing keeping nightly images working, and keeping R1/beta3 working. We can’t delay r1/beta3 indefinitely. Alternative browsers like Otter exist in haikuports which might be a viable workaround.