> > 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.
I know, that why I added "or even require its presence on the harddisk".
Think embedded system that is low on diskspace.
> 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.
Making it aware or DirectX is one thing.
Implementing DirectX in it is quite another thing.
Anyway does it _really_ need to be aware DirectX itself?
Is it not enough that it is aware of and exports
appropriate functions for the different kinds of
X11 extentions DirectX and similar DLLs might use.
> We have these x11drv-specific
> things in
> ddraw:
>
> - XVidMode
> This would also be nice for the ChangeDisplaySettings that
> OpenGL games
> use...
Indeed, but no need to be aware of DirectX or OpenGL just
export an approriate function from X11DRV.
> - 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...
That is a tricky one. I think I pass.
However adding bloat because it makes doing some things easier
is not really a good argument in general.
> - 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.
Indeed to move _some_ part of DirectInput might be the clean solution
but being aware the existance of DirectInput is not nessary just
export an appropriate function or two.
> - 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.)
Agreed (in part). But it might not require it to be aware of
existance of a Windows-like OpenGL just GLX. Same as in
the other cases.
> > 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.
True. :-)
However what I was refering to was the fact that new versions of
Wine is realeased frequently (at least in the CVS) and unless
there has been interface change you can use the same _binaries_
for several different versions of Wine.
But it your problem. _I_ don't really care.
