The Be API is not accelerated by implementation, not by design. (The same is true of QWidgets; while Qt Quick is hardware accelerated by default, QtWidgets are almost entirely not and are drawn in software. There is a QPainter backend on OpenGL, but it is not usually used here.) We could write a BView backend that used OpenGL to do drawing operations; whenever performance is an actual bottleneck, we may indeed. “Premature optimization is the root of all evil”, and all that.
Er… What do you mean by this? I don’t understand.
We control the design of app_server completely; and certainly it isn’t like XP (which did some drawing in the kernel, I think) or X11 (where there are server-side drawing functions, but they are rarely used nowadays, and window managers do a lot of heavy lifting that they shouldn’t have to were the design saner.)
Either way, we could completely rearchitect the internals of app_server tomorrow, and no-one but us and whoever reads the commit log would be the wiser. It’s very much abstracted from the APIs that developers consume, and that’s the point.
Wayland is very tied to Linux’s event models, which is a problem. But that aside, it is very much a victim of “design by committee” and “hyper-interoperability is the way of the future.” Have you read the specification for the Wayland wire protocol? It is virtually impossible to “speak” it without using an XML parser to parse specification files, and even then it’s not so straightforward to pass messages. And if you want to read the clipboard, then you have to use their equivalent of an “extension protocol” to do that; but oh no, this server doesn’t implement that protocol but uses a different one, so no clipboard for you!
That is to say, Wayland is a natural extension of the Linux philosophy: any component can be exchanged for any equivalent component. That sounds cool and all, but in practice what this means is that rough edges can never be smoothed out if it would break compatibility, or because others have already “gotten used to it.” The same is true in X11, ALSA, CUPS, etc. etc. etc.; which is most of why we use none of these. We would even prefer to have a native office suite instead of LibreOffice; but unfortunately at present we don’t.
Further, I don’t really know what “past bad design decisions” you are referring to that Wayland does not have. Obviously a lot of the legacy cruft of X11 is now gone, but so is drawcall forwarding and ssh -X, something Haiku still has (and hopefully always will.)
Wait, that’s why you think Wayland is worthwhile? Uhh … Wayland does not help us with that at all!
The userspace portions of hardware acceleration we pretty much already have (Mesa, BGLView, etc.) The lack of kernel driver support is what is blocking work from proceeding on that front. Porting or switching to Wayland does not help us one bit here, because it would make exactly the same demands of the kernel and driver stack that doing DRM acceleration in app_server would. So Wayland does nothing for us here at all.
Further, as I already said, a significant number of said toolkits don’t use acceleration at all. QtWidgets doesn’t; I believe GTK+3 supports it but it’s usually disabled in Cairo by default; and wxWidgets uses Qt or GTK+ on Linux. So where exactly are we lacking here?