LLVMpipe is for OpenGL. It could be paired with Wine’s D3D9 → OpenGL wrapper though. Lavapipe paired with DXVK could also be something to try.
Shouldn’t Wine’s D3D9 → OpenGL wrapper be the default anyway, since that is what would be able to use hardware acceleration once it is available?
Anyway, the recent developments in the project are amazing. Wine and Xlibe will allow so many more apps to run on Haiku that it opens up many more possibilities to use it as a main system for more people.
1 Like
Considering that the Vulkan driver work seems to be getting farther along, using DXVK and VKD3D (upstream or VKD3D-Proton) would prolly be the faster ways to get hardware acceleration in Wine.
2 Likes
Oh, makes sense. I’m guessing OpenGl then will work in Wine using Zink eventually. Cool!
2 Likes
Wine on Haiku currently has significant performance problem caused by poll() in wine_server. It spends significant time in kernel. wine_server seems designed to use epoll that is not available on Haiku.
31 Likes
I spend last days to creating Haiku native windowing intergation driver for Wine winehaiku.drv without using X11 or Xlib in any way. It is already quite usable and outperforms winex11.drv + Xlibe in many aspects.
Native Haiku Wine windowing intergation driver will also simplify Vulkan and DXVK integration a lot, no GLX stuff.
What works:
- Displaying window contents. Wine drawing engine is used, drawing result is displayed with BView::DrawBitmap().
- Mouse input (left, right, middle buttons, wheel).
- Keyboard input (VK_* codes translation, Haiku native keymap handling).
- Native Haiku window borders and window styles.
- Windows move, resize, show/hide.
What do not work:
- Focus contol.
- Window Z-order control.
- Wine - Haiku window position syncronization sometimes works wrong.
- Detecting screen size.
55 Likes
This is really nice.
Soon we will have a lot of windows applications that will work better than other platforms, especially due to the lightness of HAIKU which uses the minimum of available resources, giving all the rest of the resources to the applications, as it should be.
Philosophizing, HAIKU now is beautiful because it is orderly, elegant and essential.
The other os are fat and a bloated chaotic and bureaucratic waste of resources.
HAIKU attracts because this free lightness is projected on the psyche of our consciences, and in this historical phase there is a great need for this free lightness.
2 Likes
I just can’t get over how decent they look. ya, not native, but not bad either.
3 Likes
It should be noted that Wine on Linux is still struggling with its transition to Wayland. So in some ways the Haiku port is already superior.
4 Likes
This seems like the best solution. Any chance of Wine accepting the patches, and maybe supporting Haiku?
11 Likes
Thats a very good idea!
2 Likes
That looks quite good and the menus seem to be in the correct positions, unlike Wine on native Wayland without a virtual desktop. In that sense, it is already farther along than that other effort. Perhaps as a future task, look into creating a Haiku-like Windows theme?
4 Likes
Or something like uxtheme → BControlLook integration.
13 Likes
Maybe nonsense (I’m a bit inexperienced…), but I still have a CD somewhere with a 3D CAD (including photogrammetry, etc.) that I could look for … if there was even the possibility …
Requirements at that time:
Pentium PC from 200 MHz, 64MB RAM, 100MB memory,
for Win95 / 98 / ME / NT / 2000 (was queried during installation, i.e. ‘adapted’).
this would be really fun, I can’t wait to see some famous windows application, entirely with the haiku skin 
Yeah, next time JLG will have better chance to post an actual Be/Haiku screenshot.
(Not like last time where he posted a reskinned windows screenshot as BeOS).
1 Like
Is this theoretically feasible? Even on platforms officially supported by CodeWeavers (Linux, macOS), Wine doesn’t do similar kinds of integrations with GTK, Qt, or Cocoa.
1 Like
Windows 98, 2000 etc supported custom colors for normal winforms controls, it should be possible to have this be based on Haiku colors atleast.
Wine already has a theme selector build in aswell, that no linux distro makes use of this for integration is kind of wierd : )
A thread spending over half its time in poll() likely indicates either one of two things: there are thousands of FDs being run through poll (this seems rather unlikely if you only have one WINE application working), or there is an event being triggered every time poll is invoked, or within a few ms at most (much more probable.) This may be due to a bug of some sort either in WINE or in Haiku; possibly there is some error condition not being cleared. It is worth investigating on the WINE side of things to see what is precisely happening.
6 Likes
250 fd when running notepad. 264 fd when running image viewer with animation. According to my SystemManager, new sem_id with name “select” is created on each poll() call.
4 Likes