From: Maarten van Dantzich [maartenv@MICROSOFT.com] Sent: Tuesday, October 05, 1999 4:06 PM To: 'Niklas Elmqvist'; 3d-ui@hitl.washington.edu Subject: RE: 3D window management (If you don't care about redirecting 2D apps into 3D, hit delete. :) If you DO care: please send me some mail if you're attending this Virtual Worlds symposium at the HITlab next week. It'd be nice to get together with other folks who've done stuff like this and give a demo of the Task Gallery. Back to the technical details: From: Niklas Elmqvist [mailto:d97elm@dtek.chalmers.se] > you would just forego the system memory part and draw directly > into VRAM which can then be used as a texture map without further ado? Yes, exactly. Well, you have to set up some way to share the bitmap between the 2D and the 3D pipelines. > I strongly suspect OpenGL would not allow this -- there is no way to > directly access a texture map besides using a few existing routines and > the texture management scheme is hidden from the application. Yes, that's why I pointed to the unification of Win32 DCs with DirectX Surfaces. They're becoming one and the same, with an API to convert a handle to one into a handle to the other, without any performance penalty. This is coming down the pipeline. (pun intended. :) > By the way, out of curiosity: Do you let every different application > render to their own DC, or do they draw to one or several common > "desktop" DC? Every top-level window gets its own DC/bitmap. On Win32, it happens that pulldown menus and dialog boxes are implemented as top-level windows, so they get their own textures & we have to do careful positioning tricks. But a document open in an application is a subwindow and drawn into the same bitmap as the app's UI. This is a huge win over one bitmap for the whole desktop, or one desktop for each application. Although our scheme also has its downsides and yucky bits. Hopefully those will get redesigned at some point. I should point out that this is joint work with the Windows 2000 team, who did the hard parts in the OS that we needed to enable this. >> Maarten.