Upgraded haikuwebkit to 1.9.0, and I’m experiencing flicker issues on all sites that I’ve visited. Some sites are much worse than others.
I’m using vesa driver, so it shouldn’t be graphic card driver issue.
Yes, it’s faster but it flickers more. It seems we can’t have everything in that area, until someone better than me at these kind of things fixes it.
1 Like
I’ve been on Haiku a long time, and you’ve always done amazing work! Don’t be so hard on yourself!
1 Like
If this is sufficiently annoying then it probably should be resolved before the release, I guess. Likely the change in question should be reverted in HaikuPorts. Or I should spend some time trying to write a better solution…
8 Likes
@Thread
Is the framebuffer double- or triple-buffered? It seems to only affect the portion of the display being refreshed.
Please check the ticket diver linked above for a technical explanation
1 Like
I have tried to fix this in several ways since 2014 and never reached a solution that works. There are other problems I can solve, but not this one. I don’t have much motivation to try it again after this many attempts and failures.
Not really a problem, I have many other bugs to fix where I can be more useful.
If everyone prefers the slower, more memory hungry, but a little less flickering older code, it can be restored in haikuwebkit. It is just oen commit to revert and as far as I understand, people have tried that recently and there are no conflicts. Why not do it in the haikuwebkit repository instead of making a patch at haikuports? Having a diverging codebase with patches at haikuports seems to only make life harder for everyone. I am not particularly attached to keeping my messy code in there at all costs. But apparently people will only complain and no one will take the 30 seconds needed to do a “git revert” and submit a pull request to haikuwebkit? Is it that frightening of a codebase?
There are a few other things to fix too so we could make an 1.9.1 release after these fixes.
I propose to switch output back to DrawBitmap from SetViewBitmap like I did in my Haiku Wayland implementation. I haven’t observed any performance issues. WebPositive speed issues have different causes.
1 Like
Maybe submit a PR as pulkomandy asked?
I can’t. Git clone fails on WebKit repo because of out of memory.
Because WebKit repo is too huge and impossible to work with on Haiku if not a lot of RAM (16 GB+?) and disk space is available. HaikuPorts patch takes much less resources.
You can make a patch with githubs web interface iirc, it would be the same thing as doing it via haikuports patches.
In any case, it sounds like a git bug to me
(I do indeed have 32GB of ram for webkit, but it worked just fine on my laptop with 4GB of RAM, so i am not sure where the issue lies for you :/)
It seems reserve more RAM that actually needed. It can be also kernel bug.
I had 8GB of RAM on my previous computer and no problems with that. So I’m not sure what’s the difference but there must be something else in your setup that makes it not work?
Disk space is something like 5GB if you get the whole history of the repo, which you probably don’t need (so you can use a shallow clone and save a lot of space). It’s large but not unmanageable.
Thanks for the ticket link. I’ve commented there.
I just saw that on ticket #18052, haikuwebkit 1.9.3 fixes the flickering issue. Any idea when that package will be released?
1 Like
Official: haikuwebkit`1.9.2 (b6799d3, Webkit 615.1.10)
Started a test build this morning. I’ll review later…
Unofficial: Haiku patch review
- haikuwebkit - WebKitLegacy - 615.1.15.1 (updated, rebased all patches)
- haikuwebkit - WebKit2 - 615.1.15.1 (WIP)
1 Like
What does that actually mean? please explain.
Again, please explain.
Again, please explain.
1 Like