Is there are release around the corner? Just asking since some weeks SoftwareUpdater stopped telling me there are updates so I question if things are in Feature-Freeze state or if there is a problem with the update server going on.
1 Like
System updates are still broken for the moment. From what I heard, theyāre waiting for a Haiku sysadmin to return to deal with the issue (or something like that).
1 Like
Upon first glance at using Haiku(nightly 51782) the past few days, my impression is that it is a sleek, modern operating system. Why? Because it looks, acts and feels almost identical to my favorite 90ās operating system. Which by my best estimate, was at least 30 years ahead of its time. By that standard, Haiku still has plenty of time to develop and maintain relevancy as a modern OS.
Letās look at the big 3: Linux, MacOS, and Windows. For argumentās sake, lubuntu, Ubuntuās lightweight twin sibling, is my Linux comparative. None of these operating systems come anywhere close to the responsiveness, architecture, and potential that Haiku has as of writing this today.
Iāve been watching Haiku develop from afar for a number of years. I used to be active in the community a long time ago. I even attended WalterCon 2004 in Columbus, OH and was present for the the unveiling of Haikuās name. My hatās off to everyone who has stuck with it all these years, and cheers to those whoāve joined the community since then. Iām extremely excited to be back. meep meep, ribbit
5 Likes
Welcome back! 
1 Like
Iād be happy with just a hint of drop shadow for the windows (similar to the mouse cursor) and call it done for R1. Haiku is pretty darn good looking when you compare it to the likes of Windows 10, which is as ugly as its ancestor Windows XP. Obviously UI/UX innovations will come in R2. Iām guessing some of the innovative ideas, etcā¦ from the Glass Elevator project are archived somewhere(?).
Nearly all graphically worthwhile UI systems/designs are using OpenGL 2+ to produce the required effects (Compositing). Haiku is still lacking a HW GPU backend for modern systems so you need to get this out of the door before you can do reasonable Compositing on a reasonable resolution (1960+). UI lags already in the current system on 1024+. And no, SW rendering does not cut it in this case, Iām sorry You might be able to do it but wasting that much CPU time on SW rendering would be stupid.
Agreed.
But itās hard to get GPU HW support. Maybe itāll be easier with Vulkan, as it tends to homogenize the HW / SW interface.
It makes sense to go for Vulkan than OpenGL from the HW side. Software side itās more complicated though but doable if you know what you are doing. AMD/ATI certainly is the better choice to get it working in the first place.
considering haiku desktop runs just fine without hardware rendering, i donāt see what the point in adding that overhead would be. what is the modernization? what is the specific functionality youāre looking to add? chances are, whatever it is, an opengl-based compositing engine (opengl was built for software rendering, btw) wonāt be the best path to get it. the operating system should not demand specialist hardware, ever. applications might, but thatās a whole separate matter altogether.
2 Likes
This is the exact opposite of the truth. OpenGL is based on Silicon Graphicsā proprietary IRIS GL for their 3D accelerated workstations. SGI built OpenGL because they were concerned about support by other vendors of PHIGS, a standard nobody uses today but which was already open and a competitor to SGIās GL. Although OpenGL can be implemented using software, as Haiku does today, the results tend to be rather poor as youāve seen.
There is many report that a compositing engine badly affects the whole system latency (from pressing a Key down till the actual output on the screen) on other OS.
I know about no other solution, maybe there are other ways to draw efficiently on the screen, but i better like to see to use this for making things faster, not for eye-candy.
3 Likes
well, usually using GPU rendering stage introduces an at-best-one-more-frame lag, indeed. A composing engine does compose multiple render buffers at GPU rendering stage, which add to the render buffers updates stage.
Without it, aka CPU only rendering, the GPU is just busy throwing to display ouput the single renderbuffer (which is the framebuffer directly) updated during the previous frame by the CPU.
Usually the latency seen on other OS is due to the fact that render buffers (each windows content, said simply) are in system memory, not on GPU memory, because the window content is drawn by CPU code, not GPU code. The system memory -> GPU memory eats a bit of time, which when longer than frame rate, gets you lag.
Modern compositor engines uses GPU-driven graphical engine so that render buffers are drawn directly in GPU memory.
For instance Skia havean OpenGL backend that can do that. Clutter too, AFAIK.
2 Likes
It would be good if a Haiku beta was released this year, because there is expected to be a Redox OS release and probably a ReactOS release as well. It will be great to be able to compare the progress of at least 3 alternative operating systems - nirvana for any computer science grads out there.
1 Like
The fact that app_server does all of the rendering server-side may actually make things a lot more efficient for us. Basically, apps could stay unchanged and we could add an accelerated rendering backend to app_server (using Skia, OpenGL directly, or maybe OpenVG where that is supported). This would result in a single application doing OpenGL stuff in that case (limiting context switches).
There were also experiments with software compositing (by looncraz), which is already interesting because we can do more blits and less actual drawing. For example, in the current situation, when you move a window above another, both window need to be redrawn by the apps. If you use compositing, no redraw at all needs to happen, just blitting the window buffers to the screen buffer. For complex enough windows, this may end up being faster.
3 Likes
Agreed, that two very valid points to me too.
The issue alas remains the same: itās hard to write HW GPU drivers, and porting the existing ones hit the Linux wall way too often, even if the DRI/DRM are supposed to be platform agnostic, theyāre really not in their implementation, as show by last GSoC project failureā¦
On the half full glass side, both Intel and AMD support is fully open sourced by their respective HW makers, which is a better situation than 15 years ago when no one was and only reverse-engineered code for Linux only was available.
With intel mGPU being available in more and more computers, from Laptop to even desktop, thatās narrow a bit the HW landscape to support first.
1 Like
It may be interesting to look at Fuchsia/Magenta/Zircon video drivers instead of Linux ones. I donāt know how easy it would be to port these, but I least I expect a little more stability in ABI and interfaces there?
2 Likes
Dunno, looking at Zircon git master branch I failed to find anything but simple framebuffer kernel drivers.
While Skia can run with an OpenGL[ES] or Vulkan backend, I guess there not yet support for that in Fuschia.
EDIT: seems that I was looking wrong:
3 Likes
How is wayland doing in this context? Is it also based on DRI/DRM or has it some own magic going on? Iām not in the loop there since Iām working on OpenGL level where this kind of low-level dabbling is none of my business in the first place.
1 Like
How do you see it? Hard?
opengl has been built for software rendering since before quake came out, i really donāt and wonāt ever care what the origin is, itās been great at software rendering for over twenty years and software rendering remains a target.