Although it would be interesting having the GDI winsys running on WinCE
several Windows GDI API functions and data structures are missing from
WinCE headers, making this far from a trivial endeavor.
If an app (like progs/samples/blendxor.c) includes both gl.h and glext.h
this typedef will get hit in both headers, causing an error.
Possibly work around by bringing GL_NV_geometry_program4 items into gl.h.
It could only be called from XMesaCopySubBuffer but this function is not used
by XFree86.
It seems that XMesaPutImageHelper would handle sub-images but never got
finished. Proper sub-image helpers should be written if need be.
This uses xmesa.h as the GLcore interface and avoids adding an explicit GLcore
inteface which would not be a proper interface anyway.
It puts the declarations of the three functions specific for XMesa/XFree86 in
xmesa.h, we can push them down to xmesa_xf86.h if hiding behind XFree86Server
ifdef's is not enough.
Drop XMesaSetVisualDisplay(), XMesaReset(), no longer used.
Add XMesaCopyContext() and move the GlxSetRenderTables() call for XGL within
XMesaForceCurrent(). This is to make xserver/GL/mesa/X/xf86glx.c unaware of
Mesa internals.
Also, clean some ifdef's to make it clear that USE_XSHM and XFree86Server are
mutually exclusive.
Lastly,
- move gcstruct.h from glxheader.h up to xmesa_xf86.h since it calls *gc->ops
- drop GL/glxtokens.h from xm_api|dd.c, GLX tokens come from glcore.h and are
used irrelevant of XFree86.
The old GLcore interface was replaced in Xorg 7.1 with the addition of AIGLX,
it is only used by DDX's which are known not to work with the new DIX glx code.
---
Bug 9285: misc glcore, xmesa cleanups
ACKed by Ian Romanick.
With this, tools like ximagesrc in gstreamer correctly see updates from GL
rendering. Support requires that the Xdamage library be current (but will be
disabled if not present) plus a new X Server with support for the new
XDamagePost request. libGL now has a new interface version, and also links
against libXdamage and libXfixes to support it, but backwards compatibility
is retained.
Currently, all drivers report damage at SwapBuffers time through common code --
front buffer rendering doesn't result in damage being reported. Also, the
damage is against the root window, as our drivers don't yet render to backing
store when they should (composited environments).
Jonathan White