On Wed, 10 Jan 2001, Patrik Stridvall wrote:
> > I've been thinking about going about all this in a different
> > way. Instead
> > of loading up dlls/ddraw with driver-dependent code, perhaps we should
> > consider driver separation not only in dsound (like it's done
> > now, with
> > IDsDriver in the wineoss driver), and like I want to do with dinput
> > (IDiDriver in winmm's joystick driver etc), but also in ddraw?
> >
> > So the x11drv (and any future graphics drivers) would export a
> > IDdDriver-or-whatever-it's-called COM interface, that dlls/ddraw could
> > then build upon, just like in windoze. All the DGA, DXGrab,
> > and GLX code
> > would then have to be moved into the x11drv, obviously, so
> > it'd be a lot
> > of work, but it'd certainly give us some advantages as well...
>
> Good idea (almost).
>
> However I don't think we should put DirectX related X11 stuff
> directly in x11drv it bloats it to much. Most applications don't
> use DirectX so it shouldn't need to load it in memory or even
> require its presence on the harddisk.
Unused parts of binaries aren't loaded into memory. Only when referenced
are they paged in from disk.
Besides, apart from that there are good reasons to make the core x11drv
aware of DirectX, something unachievable by just layering on top, the
bloat wouldn't be all that big. We have these x11drv-specific things in
ddraw:
- XVidMode
This would also be nice for the ChangeDisplaySettings that OpenGL games
use...
- DGA2
Not all that much code, yet integrating the x11drv with this might make it
quite easy to fix the Battle.net display problems, where Battle.net mixes
GDI/USER and DirectDraw access...
- DXGrab
Well, here'a another reason for making x11drv aware of DirectX -
even with DXGrab, Lionel Ulmer with his DirectInput code has experienced
problems with mouse input after a resolution switch, because the core
input code needs to be aware of the new resolution. As I remember
Alexandre rejected his ad-hoc solution, the clean solution would be to
move some part of DirectInput processing into the x11drv. The DXGrab could
just be integrated with this.
- GLX
Now here's where the bloat might be. But I don't think we want to move all
of the GL code in here. The x11drv could just export GLX stuff like
"create_gl_context", "set_gl_context", which obviously just manages the
context (and the window), then the dlls/ddraw code takes care of the rest
(using standard system-independent OpenGL calls). Lots of portability to
be gained here... without adding too much code to x11drv. (Most 3D work
would then still be local to ddraw, since it's the GL part that's hard,
not the GLX part.)
> Perhaps this will also help you (Transgaming) to easier be able
> to distribute your special version in _binary_ form. Just distribute
> your own libddraw.so and libddraw_x11drv.so or perhaps even
> just libddraw_x11drv.so. If you implement everything in the x11drv
> it will be somewhat harder to keep in sync since the x11drv might
> have changed in the main tree.
Nah, unlike corel, we do frequent merges.
