Valid point… still once you use it you end up doing things that make software rendering both slow and impractical. Same as with webkit… yes technically you can render without any acceleration but… its masochistic.
This is just blatantly false. Try running Firefox with GPU acceleration disabled. It’s slightly slower (only occasionally noticeably so) and will use more CPU, but it is no way unusable when no GPU is available.
Again, they are doing 2D drawing, and most of the drawing they do is based on system APIs for control styling anyway. How, precisely, are they going to do anything that makes software rendering “slow and impractical”? Overdraw every pixel 200 times?
I have not used WebKit without acceleration outside of Haiku, so I actually have no idea either way here. But I find this extremely difficult to believe.
Dunno, perhaps you should walk away from this discussion if all you can do is be negative and against progress. Putting up with things being slower, is about the most un BeOS mentality ever…
I’m not “against progress” here, nor is this about “putting up with things being slower”; I am, however, against blatantly incorrect statements and claims, like “web browsing is masochistically slow without GPU acceleration nowadays.”
I just disabled all hardware acceleration and related features in my Firefox, that I am typing this from (on Windows, on an i3 mobile processor, so not the fastest thing in the world), and I can only notice the difference when I pay very, very close attention to the screen when scrolling rapidly (there is barely perceptible tearing, I think, and it’s not even always there.) I even opened about:support to make sure that all features under the “Graphics Decision Log” are disabled (no HW compositing – “disabled by user: Disabled by pref”, no Direct3D, no Direct2D, no WebRender, no OMTP.)
1 Like
It’s subjective and that is why I have been trying to get across… it doesn’t matter if you are technically correct if you are subjectively much worse than every other OS on the block.
I think there is a little NIH syndrome and boxed in thinking on this topic… some spitballing ideas and general open-mindedness to finding a fast, and effective way to do this stuff ignoring 20 year old implementations would be in order. Because clearly everyone in this thread has had some valuable input… and we are all unhappy with various aspects of Haiku’s graphics subsystems is the general takeaway.
When you consider the most advanced driver right now supports at best 25% of the features of an integrated graphics card even just in 2D… and that is being generous, I mean I’m open to suggestions…
The current work done to port Mesa 20.0.x to Haiku is commendable.
- GLteapot and libSDL resolution
- GLteapot hit testing with Mesa 17
- libSDL developer requesting info on Haiku-specific patch finalization for his next release cycle.
This is the part where I feel we can accomplish a merge before R1B2 release.
DRM kernel submodel may take some time to get right…
3 Likes
To be fair on macOS at least, the equivalent ‘browsing experience’ that Haiku has right now is similar to when you boot macOS in ‘safe mode’ which disables the GPU-acceleration for the Quartz Compositor i.e. QE/CI [0]. It is comparable to Haiku’s browsing experience with WebPositive and if you’re using Safari on macOS and it is clearly not great to use since the desktop also locks up too often. It is also worse on Firefox and Chromium. Maybe there’s a way to disable all desktop acceleration on Windows to see what happens but I haven’t tried this on Windows.
While it’s possible to browse the web without acceleration, it is still noticeably slow and frustrating to use.
[0] https://en.wikipedia.org/wiki/Quartz_Compositor#Quartz_Extreme
1 Like
Ah, ok why? Computers are cheap these days!
I like to have my one man Haiku system and I will buy one for my wife and two for my children. So I can work when I need my Haiku PC, what is the benefit of a multi-user Haiku PC? Who is we? This level of discussion I cannot understand!
Maybe a poll will help after Beta2 is released?!
2 Likes
Because people wanted multi user and real security back in BeOS days… it would hopefully end up being more like windows NT 2000… everyone is an admin etc… guest accounts are just opening a can of worms that for instance windows and Linux are still coping with today so probably not worth it.
Windows isn’t really “coping” with it anymore (though they are a completely, completely different beast than Linux, BSD, or Haiku, so they are not a good point of comparison.)
Linux is, uh, still coping with the fact that it is Linux. Most of the clunkiness of how it manages multiuser GUI is much the same as the clunkiness of the GUI in general. And the same is true on BSD. I don’t think we can really draw points of comparison there either.
2 Likes
Security can be archived without a multi user Haiku system!?
One Computer with one Password will be not enough?
Files are protected by username right now? Don’t they?
An old worn out argument… lets no go there here and not it’s a waste of time…
Lets remember that multi user and multi account are technically different things. No modern OS really should be without multi user… and multi account is desirable and honestly relatively trivial. It’s even been done before on BeOS/and it’s kin.
Haiku is already multiuser.
Yes you are right maybe, get back to R1Beta2 and let us discuss that and 3D acceleration later… Thanks to the devs hard work here!
I totally agree with him at this point! Leave it as is!
X512 is a non using IRC Haiku dev!
And he is one of my Haiku top devs!
Well everyone has treated my thread as if it were IRC so… >:D
1 Like
But that checklist are useful, yeah Haiku now have office suite, and it make the operating system less useless, is the same with the gpu support, if we dont need graphics then we can pick a fbsd withouth xorg and it would be enough. And yes, when we have a 3d support we will want to have a good modern web browser to stay on haiku all the time and dont have to use linux, windows or fbsd. Is not so weird.
we need gpu support, obviusly we need a lot of things but it is a good start, or the office suite was so unuseful? no, is very useful.
1 Like
I’m joking of course but… what one person has gotten used to does not tend to match what most people would accept adapting to or even tolerate. Setting goals based on what the developers can tolerate… is well…intolerable to outside users.
1 Like
the alternative is simple here:
- I listen to you
- I put my focus on 3D acceleration that I don’t care about
- I can’t use my VGA display and I can’t use my web browser (the two things I’m working on currently)
- I give up, and start using Linux instead so I can use these two
- I stop working on Haiku
- Users still don’t get 3D acceleration
Is that a winning situation for you? It seems not for me.
So, I’ll keep my motivation for things that allows me to continue to run Haiku. It’s that simple. If I can’t achieve that, I’ll give up and use another OS. That’s all. We will look at 3D someday but at the moment I have much more important problems to deal with. There is no point racing into 3D support and letting all other parts of the OS fall apart.
8 Likes
@PulkoMandy I thought you weren’t the lead developer of Haiku a point you were very adamant about… there is a massive disconnect between your points and that. Nobody is asking anything of you personally. Keep doing what YOU do best and what you enjoy and that we continue to appreciate… all of this is tangential to that. If it happens it happens if not … nobodies fault really this is free software and people have priorities outside of Haiku and even different priorities as developers. Lets just continue to have this conversation and share ideas… honestly it feels way better than stagnation even if a few feathers get ruffled here or there.
Personally, I think the Haiku graphics architecture as far as kernel and drivers has been going down the wrong path… since it is so hard to get people with the skill and interest, the path of least resistance should be taken, basically port the entire Linux graphics stack with virtually no changes, and run app server on top of that if they dont’ have an accelerated driver at least the direct ported Linux Vesa drivers and fb drivers would provide basically identical support to what we have now, except support for newer hardware could just be direct ported the similarly to how the wifi and ethernet drivers from BSD are handled. From all I’ve read the advantages of the Haiku kernel have little to nothing to do with graphics drivers… since that design is stuck in 1998, so honestly why not just replace it with something completely new if it has no affect outside of the kernel itself (execpt maybe the screen/display preflet apps would need overhauls).
That would not even mean adopting wayland necessarily… even though I think that could work and would likely be less long term effort since it would imply more shared work with Linux. That basically leaves implemeting app server directly on KMS/DRM or on top of wayland… I would think the latter would be less work and have the potential for easier long term maintenance.
There are extremely few BeOS applications that interface with that side of things after all… so changing things to be maintainable… would be a big boon for everyone.
1 Like
Porting DRM and hardware accelerated graphics drivers can be done without any changes in userland Haiku code at all. Just add accelerant that setup framebuffer for app_server and make OpenGL render to offscreen GPU buffer, copy it to BBitmap and draw with BView::DrawBitmap. DRM drivers can be located in HaikuPorts and be optional. Any architecture improvements can be done later.
I already suggested that in Hardware graphics acceleration port idea.
Interacting with DRM to enumerate screens and setup framebuffer is not difficult. Porting Wayland feels more difficult for me and there are no need in it at all.
2 Likes