I have the same flashing white box under the cursor
1 Like
It is looper must be locked before proceeding · Issue #9 · X547/wayland-server · GitHub and it is actually use after free, not missing lock.
4 Likes
It is Haiku core issue: #15920 (app_server: back buffer is flushed before drawing is finished) – Haiku.
5 Likes
Thanks for the clarification, was mislead by the debugger message which is normally right on spot…
I updated my system with R1/beta5 hrev57937+129,
and then downloaded iceweasel from the HaikuDepot.
It says nightly 128.5 0esr.
It’s very fast and it opened all the sites I visited immediately.
Video and sound work perfectly.
A few crashes, but it’s so fast that
you almost don’t care!
I’ve been using Haiku since Dec 2022,
when the R1/beta 4 appeared,
and it’s the first time that I can use a good browser, under Haiku.
So,
keep up the good work, guys!
Thanks for this functional browser,
and let me thank the Debian Project, who made
this rebranded version of Mozilla Firefox, too.
3 Likes
Some of it may be an app_server inefficiency. There’s high CPU usage in the main window thread it appears, and a very strange dropoff between BitmapPainter::Draw (81% of CPU time) and the next function, memcpy (14% of CPU time). Seeing if we can optimize that will be interesting.
But if there’s so much CPU time spent there, perhaps the Wayland server implementation is redrawing far too much rather than just what’s dirty, and that could be optimized too?
2 Likes
(I also see that a significant number of Gecko/Iceweasel threads spend half or more of their time in malloc/free and related functions. We really need to replace our malloc implementation – and I’ve been slowly working on that again recently…)
6 Likes
Here’s the WIP patch I came up with for wayland_server to improve efficiency with Iceweasel; however the invalidation code doesn’t work quite right:
From 7264d6e283cccc5003321552d96f90ef9ad2782f Mon Sep 17 00:00:00 2001
From: waddlesplash <waddlesplash@gmail.com>
Date: Tue, 10 Dec 2024 15:30:51 -0500
Subject: [PATCH] WIP (doesn't work right): efficiency improvements.
---
HaikuCompositor.cpp | 15 ++++++++++-----
HaikuSubcompositor.cpp | 5 ++++-
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/HaikuCompositor.cpp b/HaikuCompositor.cpp
index 3ea87db..f1ec212 100644
--- a/HaikuCompositor.cpp
+++ b/HaikuCompositor.cpp
@@ -134,7 +134,6 @@ WaylandView::WaylandView(HaikuSurface *surface):
BView(BRect(), "WaylandView", B_FOLLOW_NONE, B_WILL_DRAW | B_TRANSPARENT_BACKGROUND),
fSurface(surface)
{
- SetDrawingMode(B_OP_ALPHA);
SetViewColor(B_TRANSPARENT_COLOR);
}
@@ -276,10 +275,16 @@ void HaikuSurface::Invalidate()
return;
}
auto viewLocked = AppKitPtrs::LockedPtr(fView);
- if (fSubsurface != NULL) {
- viewLocked->Invalidate();
- } else {
- viewLocked->Invalidate(&fDirty);
+ viewLocked->Invalidate(&fDirty);
+ for (HaikuSubsurface *subsurface = SurfaceList().First(); subsurface != NULL; subsurface = SurfaceList().GetNext(subsurface)) {
+ HaikuSurface* surface = subsurface->Surface();
+ BView* subsurfaceView = surface->View();
+ BRegion subsurfaceFrame = subsurfaceView->Frame();
+ BRegion subsurfaceDirty = fDirty;
+ subsurfaceDirty.IntersectWith(&subsurfaceFrame);
+ subsurfaceDirty.OffsetBy(-subsurfaceView->LeftTop());
+ surface->fDirty.Include(&subsurfaceDirty);
+ surface->Invalidate();
}
fDirty.MakeEmpty();
}
diff --git a/HaikuSubcompositor.cpp b/HaikuSubcompositor.cpp
index 9b34e01..c60dce5 100644
--- a/HaikuSubcompositor.cpp
+++ b/HaikuSubcompositor.cpp
@@ -87,9 +87,12 @@ HaikuSubsurface *HaikuSubsurface::Create(struct wl_client *client, uint32_t vers
subsurface->fParent = HaikuSurface::FromResource(parent);
subsurface->fParent->SurfaceList().Insert(subsurface);
haikuSurface->SetHook(new SubsurfaceHook());
-
+
BView *parentView = subsurface->fParent->View();
if (parentView) {
+ parentView->SetDrawingMode(B_OP_ALPHA);
+ parentView->SetViewColor(B_TRANSPARENT_COLOR);
+
haikuSurface->AttachView(parentView);
haikuSurface->AttachViewsToEarlierSubsurfaces();
}
--
2.45.2
Dirty region invalidation is currently disabled for Firefox because it do not work correctly. It need more investigation. Dirty region invalidation works fine for regular GTK applications.
3 Likes
It should be not needed because B_TRANSPARENT_BACKGROUND already do so.
Gecko has vendored jemalloc impl to reduce memory fragmentation and allocator replacement mechanism, so we may be able to utilize that.
https://searchfox.org/mozilla-esr128/source/build/moz.configure/memory.configure#8
EDIT: old article on this
- Firefox 3 Memory Usage | blog.pavlov.net
- linked from jemalloc’s history: Background · jemalloc/jemalloc Wiki · GitHub
5 Likes
Ah, you mean the dirty region updating is the problem, and no loop is needed here? Alright, makes sense.
Yes, may be worth a try. Though jemalloc may wind up wasting too much memory (if it’s designed with overcommitting in mind); we’ll have to see what happens.
3 Likes
Yes, switching system allocator to Mimalloc or OpenBSD allocator should fix problem. Personally I prefer Mimalloc because it is top class efficiency allocator used in projects that care performance like Mold linker. It is also designed to work properly in systems without overcommit.
5 Likes
4 posts were split to a new topic: OpenBSD malloc has manu peculiarities
Still get the infamous crash from
with every browser session:(
Can I help testing a preliminary wayland version?
2 Likes
I came up with a potential fix that works, but @X512 rejected it due to breaking some conventions he’d set.
I’ll look into fixing it a different way later.
4 Likes
Nice to see you thinking along, just wished the wording would be different, no need to call in the rejection (that should be done upstream). Just my 2 cents.
3 Likes
Just saw that there is a new build (128.5.0-4) on HaikuDepot.
I would love if there was a change list included in the receipes on HaikuDepot for every new build like a rpm spec file.
4 Likes
The new package just has a fix to the dependency declaration for one of the libraries, it’s not a new build.
4 Likes
