From: Niklas Elmqvist [d97elm@dtek.chalmers.se]
Sent: Tuesday, October 05, 1999 3:47 PM
To: 3d-ui@hitl.washington.edu
Subject: RE: 3D window management


On Tue, 5 Oct 1999, Maarten van Dantzich wrote:

> Jerry Isdale said:
> > One approach I'd like to see is using 2d hardware as direct sources for
> > bitmaps into the 3d world.  Instead of feeding a video converter, the 2d
> > frame would feed (be sampled) into texture memory 
> 
> What exactly did you mean here?  That you want to preserve 2D drawing
> acceleration (GDI acceleration, under Windows) and still texture map the
> result into a 3D scene?  That's not so far-fetched. We've certainly
> discussed it here at MS as a desirable extension of the App Redirection
> architecture that we have implemented right now. 

Hmm, yes, I think I see your point here. In 3Dwm, we have to let the X
server draw into shared memory (either full-fledged IPC shared memory, or
just "light-weight" shared memory between the X server thread and the 3Dwm
rendering thread) and then upload the texture to OpenGL. Most graphics
cards don't allow rendering in normal system memory (they keep their own
video memory, so can't really be expected to do this). How would you cope
with this? Oh, wait a minute, I see your point -- 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?

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.

> It might not even be THAT hard, since unification of GDI DCs and DX Surfaces
> is happening in Win2000. You'd do it on a single video card, 2D apps using
> the GDI paths into a DC bitmap allocated in VRAM, which you then also access
> as a texture surface. The main issue is locking/synchronization or coming up
> with a clever double-buffering scheme that doesn't break the "update region"
> optimization in the GDI painting model. Of course the changes do have to
> happen at the low system level, and it's hard to get cycles from the Win2000
> and Direct X teams for such far-out things... but not unimaginable.

No... I can see how it might be beneficial to work on this when you have
the power to alter the operating system running it! :)

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? Do every subwindow (such as dialogs to an application) get their own
DC, or do they draw to the parent DC?

I'm asking because in 3Dwm and X11, this didn't prove very simple to do
without a major rewrite of Xvfb and much of the X server code it is using.
So instead we made use of the screen concept of X11, and this might
actually have become more cleaner than any other scheme -- many
applications support the "-display :x.y" syntax, where x is the display
(normally 1, since 0 would be the conventional X server running on the
host machine and taking care of the console window system) and y is the
screen number. When clients connect to the display, we simply spawn a new
screen with a color depth and size that the app requested. In other words,
we seamlessly create a separate desktop, if you will, for every single
application.

(Hopefully, we're not going too far off-topic here; in that case, others
will have to holler!)

[snip]

/Nick

-- Niklas Elmqvist (d97elm@dtek.chalmers.se) ----------------------
  "One of the universal rules of happiness is: always be wary of any
   helpful item that weighs less than its operating manual."
           -- Terry Pratchett, Jingo