While I agree that we need to address the issues in WebPositive and WebKit which I respect your hard work on and possibly migrating it to WebKit2, most first time users will still continue to complain that it is ‘not a real browser’ or ‘not a modern web browser’ (even though it using modern web technologies as it being WebKit based) such that it is immediately dismissed if it doesn’t render their selected website.
As you said, the expectations are increasing for us to catch up and improve Haiku. At least for me, we need to eventually look at getting more of the alternative web browsers on Haiku (Firefox, Chromium, QtWebEngine-based ones, etc) so that we can confidently say that it exists and it works on Haiku. The same was said for LibreOffice and no-one requests for it anymore.
I agree. A guided / automated installer mode should be in-place which supports EFI installation should simplify the installation process and leaves the current installation we have as ‘advanced mode.’
New, unexperienced, common users are our target audience. The website starts with “Haiku is easy to use”. We get the reviews we asked for.
If our website sais “Haiku is for high tech skilled users only. Do not try this at home” we would get a different kind of review, maybe.
That’s unacceptable. We should fix the bugs, not tell users “yes ok it doesn’t work on the first try, but you can use this other app, hold this button a little longer”.
Imagine Haiku was a car. Telling the user “ok, the steering wheel doesn’t work, but you have a choice of other steering wheels here, this one can turn left, and this other one can turn right, so you can still drive”. Ok, great, but I won’t put that car on the road. And I think it’s safe to stop the review there if you are a car reviewer. That’s what happened. No working web browser, no review. No working steering wheel, no review. It’s that simple.
Let’s fix our bugs. And let’s show this review to people who think we should not be in beta anymore and make a final R1 release: it explains it exactly.
I’m having a good experience with Haiku Beta 2 on my Thinkpad R60, so I decided to post a reply on the comment section of Jim’s review, which I found very harsh. you can read it here.
I was testing the actual live stream from Apple during the event, and also trying the same recorded video
which was crashing Web+.
Now, Web+ doesn’t crash during the entire recorded video playback of Apple WWDC 2020. I let Web+ play
other YouTube videos for 2-3 hours with zero crashes nor very high memory consumption (in regards to Otter for comparison).
I’ve streamed/recorded live radio and video using Haiku as a media server or a client.
FFmpeg caused some previous issues as well as some Web+ bugs. After recent updates, seems like things are working better now.
I install beta2 for some minutes and i looked into the readme.md file. There is no info about installing, work with the uncompressed image of haiku. Should be included
come on. making up things (or massively exaggerating), even implying good intentions is still a bad idea. I use 12 y.o. computer as my home computer. It runs 7 now and I didn’t have troubles with youtube. nor vimeo. and videos, grabbed from yt and run in the video player instead of browser, almost don’t load CPU at all (yeah, 1920x1080 h264 almost doesn’t load CPU! ~1% or less most of the time). moreover, IE11 runs on a home W7 laptop (newer, but old too) still shows video with less CPU load than all that modern Mozilla Firefox.
which is what I want to make a note about. I did notice the poorly hidden negative attitude of the author towards Haiku, that’s obvious, of course “good article” shouldn’t necessarily be all that sugary “wow, awesome” bombarding. but at least trying to sound more balanced, would be better. and also on browsers, like it or not, but that’s really one of the first programs, users want to check out, so lack of such (or bad functionality of present ones) hurts the OS badly. on the other hand, browsers have become the most bloated and monstrous hogs in software. so porting them is nearly impossible to a project driven purely by enthusiasm. however, I doubt this kind of articles can hurt the project.
Hardware video acceleration really helps a lot, and I suspect if some work was made on that for Haiku it would greatly improve the YouTube situation. I am still learning about this but I think it could be supported without also having to implement the full GPU acceleration stack as well. Though I am probably wrong
It would also be a nice test to download the same videos in Haiku and run them in MediaPlayer and see what the CPU usage is like on the same computer to see how much help there is from the hardware video decoding acceleration.
Also in general twelve year old computers (circa 2008) really aren’t that bad. CPUs have not advanced that much in that time. I have a desktop machine I built in 2011 which is still very fast and yeah, Youtube is not an issue on it. It can build all of Haiku from scratch in 10 minutes or so. It has a 4C/8T i7 2600k and an Intel SSD and was pretty nice in 2011. I still prefer my 6 month old Ryzen desktop though!
The only thing really stressing modern machines or even 10 year old machines is 4K video, advanced games pushing out billions of triangles a second and maybe compiling complicated languages like Rust or modern C++
From my knowledge, you are indeed wrong, as GPU video decoding generally goes through the same memory management and other command structures as the rasterization pipeline does.
Fair enough. I still wonder if it might be an easier place to start. As well as just picking a piece of hardware like Intel HD and take that deep rather than trying to go broad and support all the GPUs. But I am just starting to learn this stuff.
Should be noted that GPUs from the last couple of years need firmware in order to properly work, regardless of OS or driver used. Haiku would prolly have to ship these firmware blobs at some point when trying to support them.
Almost zero, unless you pick 4K video. And our youtube is stuck in 480p or something so that’s not the problem.
I think the main problem is getting the decoded video to the screen: it gets decoded to a BBitmap, which is then copied to the webkit offscreen buffer (with resizing), and copied again to the webpage.
One thing we could do is implement fullscreen videos in WebKit with direct copy to screen. And see how to optimize rendering to the webpage, with less copies between buffers.
Yes, but if we do it for the whole webpage drawing in the current state it could be a quite long update session resulting in frame skipping for the whole app_server?
Update session do not globally lock app_server. Inside update session all window drawing is done on screen back buffer and when update session is finished, back buffer is copied to front buffer. Each window can have independent update session and do not affect another windows.
Not yet. There’s much wrong with the current Quick Tour (see ##15430), unfortunately, when compared to my “manually” created package. I’m quite unhappy about it…
making up things (or massively exaggerating), even implying good intentions is still a bad idea. I use 12 y.o. computer as my home computer. It runs 7 now and I didn’t have troubles with youtube. nor vimeo. and videos, grabbed from yt and run in the video player instead of browser, almost don’t load CPU at all (yeah, 1920x1080 h264 almost doesn’t load CPU! ~1% or less most of the time). moreover, IE11 runs on a home W7 laptop (newer, but old too) still shows video with less CPU load than all that modern Mozilla Firefox.
