http://bugs.winehq.org/show_bug.cgi?id=5955
------- Additional Comments From stefandoesinger@gmx.at 2007-29-03 09:49 ------- Ok, maybe I overreacted a bit to J.Nicolaisen comments which perfectly fitted into my "OMG!!1!1 Use flags!!!" Gentoo user scheme(Beeing a Gentoo user myself, for the record).
As I have described in my rantish comments above, the Problem is part of the (nonexistant) scheme how Wine(or wine parts) connects to the windowing system. Right now that is only X11, but in near future there will be MacOS and native Windows too.
So there are different interests in that field:
*) In this bug a weak connection is requested, doing everything at run time to get the maximum of features with an existing system setup.
*) 3D gamers have a full system set up already. They want something that adds the least runtime overhead.
*) For using wined3d on windows we'll need wined3d to link to opengl.dll
*) MacOS users don't want to use an X server. We have to use AGL natively
*) Alexandre wants an approach that is as clean as possible
*) Gamers want to be able to select pixel formats at runtime
It is comparably easy to fix the symptom of this bug, but the effort for that fix will be lost when the other issues are addressed. Most things can be fixed by stacking up abstraction layers. Performance issues that arise with that can be circumvented with adding shortcuts through those layers, at the cost of code cleanness. I don't have a solution handy that suits everything.
The current plan is to go the abstraction layer stacking approach, but wine's opengl isn't ready yet to run wined3d. Roderick Colenbrander is working on opengl, but his time is very limited too. I don't know what is missing precicely, but I think it is in the area of extension handling and windowed opengl rendering.