On Tue, Apr 3, 2012 at 4:41 AM, Jon TURNEY <jon.tur...@dronecode.org.uk> wrote: > On 27/03/2012 05:09, Jamey Sharp wrote: >> However, our capstone project that just finished was a start toward >> replacing the XQuartz DDX with a stock Xorg server and a special >> client, and I'm hoping that XWin can go the same direction. > > This is certainly the approach I'd like to take, as well, rather than stuffing > all the WM integration code into a client thread inside the X server. > > However, replacing the Win32 native XWin (as opposed to an XWin built to use > the cygwin layer) with the Xorg DDX seems like it would involve a non-trivial > amount of work, in effectively porting the Xorg DDX to the Win32 API.
I'd be really interested to know how much of the Xorg DDX relies on POSIX and how much is straight C. The module loader is an obvious candidate for pain, but once you turn off stuff like the PCI layer that doesn't matter on Windows, how much non-portable stuff is left? I'm going to propose another student capstone project in a couple of weeks, and I haven't actually decided what to ask the students for yet. If you can sort out pretty soon how much work is really involved here, we could try getting a team of five or six students to do it over the next six months. If we go that direction, I'd also need one or two XWin developers to co-sponsor the project with me, committing to being available for the platform-specific questions I can't answer. It'd help if you could get to Portland at least once during the project, too... >> http://cgit.freedesktop.org/xorg/lib/libxcwm/ > > Thanks. I know you have mentioned this project previously and I'll try to > make the time to take a look at it. Much appreciated! > Is there a way to support hardware-accelerated GL in that arrangement? I hope so. :-) First, write Mesa and Xorg video driver bits that use the platform-native accelerated rendering APIs, but only allocate off-screen video memory, even for Window objects. If you can do DRI-like 3D rendering on Windows, then at least the really expensive part of 3D rendering can be accelerated, even if the libxcwm-based client still uses GetImage to read back the results. (For extra bonus points, use the glamor library in this driver to hardware-accelerate 2D rendering as well. Wheee!) After that, if you can also provide an OpenGL texture-from-pixmap extension, then libxcwm can replace the slow GetImage path with a hardware-accelerated blit from the back-buffers the server owns to the native windows created by the libxcwm-based client. Combined with the Composite extension's NameWindowPixmap request, this is just like a GL compositor such as Compiz. That gets you fast updates of any rendering, 2D or 3D, onto the real display. Implementing texture-from-pixmap is the tricky part, because it requires that processes in different address spaces be permitted to share textures. Linux DRI can do that; Jeremy tells me that given the public APIs on OS X, it's tricky at best. Does Windows allow it? Jamey _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel