There was once a version of Linux with a 3D desktop - called project looking glass. It was essentially a java app (employing scene graph technology from java 3d) used to interoperate with X-Org desktop environment. It turned X-Org into a cross between a 3D gaming environment and a desktop - much more impressive than 3D desktop effects that you get with compiz, etc. The project was going to be ported to Windows and MAC, but Sun pulled the plug due to other priorities.
Nowadays, there are more java 3D tools, as well as the more concise programming language of Kotlin. So. hypothetically speaking, if Haiku had 3D acceleration, some java 3D tools, and Kotlin - how difficult would it be to create a 3D desktop environment in Haiku compared to Linux - i.e., how hard would it be to interoperate a java 3D app with the Haiku desktop/window manager code?
During the last couple of weeks, I had Ubuntu 18.04/10 running on my MacBook Pro, using the nVidia GT750M propriatery driver. I dont know what Unity/Gnome 3.30 was doing, but the laptop fans were driving me nuts. The CPU temperature was constant 95’C. I tried various settings to reduce CPU load, even going as far as disabling ACPI interrupts GPE16 and 17, setting the laptop to always run in battery (low power mode), and managed to reduce the temperature to 75’C, where the fan would periodically come on every 30 seconds until it cooled down the laptop to 55’C, and then rinse/repeat. When I booted into console mode only (no X Server, no nVidia driver), I hardly ever heard the fan. Using Haiku with framebuffer or VESA driver is also a pleasant quiet experience.
If Haiku was fortunate to have 3D accelerated drivers, I would probably prefer NOT to use a fancy 3D desktop due to heat dissipation. Most times I disable all desktop animations since they have a perceived GUI latency. I like instant responsive interfaces, that’s why I love Haiku.
Do you realize it’s a bit of a “if you have 95% of the work done, how hard are the last 5%?” ?
Anyways, you would need to plug into app_server, as its the one managing windows. There is an article about “how to turn app_server into a compositing system”, which explains what needs to change so that it renders each window to a separate texture, and then composite everything together for display. I think this would be the extra required step. Once you have that done, you will notice you don’t need any Java. Unless your plan is to replace app_server with a Java app, but, I don’t really see the point?
Technically this would not require 3d acceleration as such. It would only require the 3D APIs, which are already there. So lack of acceleration would not prevent work being done on this. It would just mean it is not accelerated.
Also, nobody would want a Java based appserver, as mentioned above. There’s no reason this couldn’t be implemented in native C++. Sun made their demo to show what Java could do. And about that, it’s a cool demo. Not much more than that. It really isn’t practical.
Lastly, I’m with others using Haiku. We enjoy simple, efficient, fast user interfaces. That’s one of many things that made BeOS great. It’s also one of the things that Haiku prides itself on recreating. I doubt such a project would ever be part of Haiku. At least I hope not. Maybe a third party developer would be willing to show off their talents and the power of Haiku by creating a 3d desktop drop in appserver replacement for haiku. Probably not going to happen though.
I read about Looking glass, installed it in my Linux machine back in the day (not so hard, not so easy) and played for a little while. Nothing more than a demo tho, it was never “implemented” beyond the demo itself.
“We” probably cant do it because of X11 dependencies, but a 2d zoomable interface like Eagle Mode (fast, efficient) could be better than 3d ones. Despite having had fun with fsv and alikes.
Many would argue that even these things are simply flashy, resource hogging eye-candy. These effects have little to do with everyday productivity. They’re mostly glitter that make you look cool in front of your friends.
Well, Compiz certainly overdid it, but there are some interesting possibilities with compsiting.
For example the work on Metisse (http://insitu.lri.fr/metisse/) has some interesting ideas. Look at their demo videos for some example of how this can be used.
This is the kind of thing I was thinking of. A 3D or depth-type desktop would have some advantages: better manage some file searches, organising workspaces, etc., and it could be educational by showing how a filesystem is structured, and you could even represent the whole system with an image that could be explored by the user. I’m doing some reading on it, but can’t say that anything will come of it.
Compiz overdid it… but I actually liked the wobbly windows and windows that closed with 0.1sec animation into their tray location etc… the cube was cute but not that useful.
Also compiz’s requirements on the hardware were quite minimal… I even ran it on a mobile Radeon 7000 once.
Reading this thread just makes me sad. We have a person who expresses an interest in some new interface features for Haiku. Other people say, no, we don’t need any of those features. Is this the future of Haiku, “We don’t need new interface features”? This certainly wasn’t how it was with BeOS. BeOS was a playground to try new things. The whole design of BeOS, the APIs, were designed to lower the barriers to create new things. BeOS was not designed to stand still. But Haiku is now a monument to the last release of BeOS, with an unchanging interface.
I would say to people who have a vision about interface features, build a pilot study first. Don’t look for validation. Build it because Haiku as a great API that makes it easy to develop code.
The very idea of integrating Java3D into Haiku is pretty interesting. I have seen some amazingly cool 3D screen savers running in Java. Some of us really like those cool UI features such as translucent windows and use of Alpha channel effects. CPU power is cheap and getting cheaper. All this surplus CPU power could be used to great benefit for 3D rendering. If you want to run Haiku on a tiny laptop without the fan spinning, that’s an interesting use case and I won’t discourage you. But why not have the vision to have additional features that make it interesting on a PC with more capabilities?
Truly, I think we should be encouraging people to try innovative, new, even crazy things on Haiku.
I agree except for Java… perhaps something like it but definitely not written in Java. The workspace switcher could also be a composited view of the actual contents of the desktops… for example.
The Wobbly windows animation math has been split out from compiz into a library … conceivably that could even be integrated as an optional plugin into app_server once compositing is implemented. https://github.com/endlessm/libanimation
I’m in the camp of those that think things like this should be possible in a lightweight manner… certainly Haiku has put on few pounds in recent years as well… for whatever reason, take the About window for instance why does that thing take like a second to open on modern hardware… I don’t remember BeOS being that slow, my PII box opens it that fast even under heavy load. I’m not really sure what to attribute this to… I know there has been a rash of “our memory allocation or copies are plenty fast enough to abuse it in this manner”… but I’m not sure that’s it as that very well could be true. Much of the UI feels definitively sluggish compared to BeOS.
I think there is a point at which developers need to throw their fast machine out the window, and test drive on ancient hardware just to smoke test that they aren’t writing horrible code. Otherwise you end up with an OS 10 years later that is slower on hardware that is 2x as fast with virtually no extra features.
Alternatively just set the execution cap in your VM to 3-5% … and dogfood it. And optimizations based on that would not be premature… they’d be data driven. Premature optimizations implies you write some fancy code and it ends up being slower because you overthought it.
Interesting that there’s a ticket for that… it isn’t like it’s just About system though. It’s just very obvious there as it is such a simple program there is no way it should take that long to display some basic system info an image and some scrollable text.
I might remember it wrong but I think in BeOS “About BeOS” window lived libbe.so which was always loaded, so showing it was instant. I agree that apps generally launched faster in BeOS tho.
The way I remember it (are you sure you were around back then?), there was a strong emphasis on economical, light weight design that didn’t waste resources. One of their things was that the engineers were issued the same 16Mb or whatever it was at the time, as would ship with a BeBox, so they could keep it real. It’s kind of hard to translate that perspective into today’s computing scene, but that’s at least part of what you’re seeing here. Haiku has the same APIs, the same accessible platform, but I don’t remember any suggestion ever that app_server for example was wide open.
Maybe I’m just forgetting, but I don’t remember any significant changes to the graphics from DR8 to V5. They developed an elegant, usable graphic API and went on to more important things.
Hi there, Haiku developer, my machine is currently a 2011 Thinkpad X220. I got it for free from an Haiku user, otherwise I would still be running a slightly older Dell machine.
Other people take the leading edge and work on the support for new hardware. This machine doesn’t have nvme or usb3, for example.
Yet, I added an ssd and it has 8GB of ram, because I have to build webkit in a reasonable time.
Anyway, we are not adding bloat because we don’t care. We may have missed some performance problems, yet Haiku still runs a lot better than anything else. Also remember that we ship all nightlies built in debug mode, which has a noticeable performance impact. This allows us to have more useful kdl reports, which are more valuable at this point.
But we aren’t doing anything to pay attention to this either. Granted developers do respond when people notice inadvertently, but it’s just slows the creep and doesn’t really fight back against it. Perhaps some method of automated testing of desktop latency would be useful? It would probably have to run In Bochs or some other emulator where you can hold performance and resources constant though.
That’s very subjective, and certainly Haiku lacks many many features that a modern PC/Mac/Linux computer has.
If the users don’t notice the difference, does such testing bring much?
I would be happy if we would run our already existing unit tests already, which check functionality, not speed, and already don’t work.
I was referring to the delays when clicking on things here. Both Windows and Linux feel a lot worse, even if Haiu could always be made even better. On the features side, it’s another story.