native DirectX windows

[meirumeiru]

Idea: Combine DirectX and GDI to solve all the interoperability problems.

In early Windows we (at least those old enough) had Windows with a HWND and a DC and messages and we painted with GDI. Everyone knew what's going on.

Nowadays we have a mess. Why? Well, mainly because of DirectX. Because DirectX doesn't really have "Windows" or HWNDs and it doesn't (or didn't) mix well with GDI. That's why we need Xaml-Islands and stuff like that and why we have to re-invent the wheel for mouse messages and everything.

But, what if...

... Microsoft would extend the current system just a little bit. What if they'd extend the WNDCLASSEX struct? If they'd add a new class style CS_D3DDC and would provide the needed painting "DC" (of course, the equivalent for D3D) via the "BeginPaint" and "GetDC" functions (or new BeginPaintD and GetDCD functions).

Then we could use techniques we know. We would have "Windows" again even in DirectX (those would be "dummy Windows" internally) and we could mix GDI controls and windows with DirectX controls and windows by letting the system return a DirectX-DC for GDI controls on top of DirectX dialogs.

It would also allow easier techniques to support known techniques like screen readers and printing.

I think, it's at least worth to talk about it at a coffee break... somewhere in Redmond... don't you think?

[DarranRowe]

I feel that you may have misunderstood something big about how things work. While it is true that DXGI, DWM and composition enables a lot of the more modern stuff, it doesn't force it.
The big thing to remember is that, while IDXGIFactory::CreateSwapChain and IDXGIFactory::CreateSwapChainForHwnd target a HWND, it doesn't have to be the handle for a top level window. Since Vista, it has always been possible to draw an individual child window with Direct3D while using the User32 stuff. Direct2D then went on to make this interoperability easier.

[meirumeiru]

Well... I think, you didn't understand what I said. I said, that I want

a) an automatic layer that handles GDI-windows on DirectX-windows (we all know that DirectX-windows on GDI-windows work just fine) and
b) that I want HWNDs for DirectX-"things" that are painted directly together on a DirectX-window and that those HWND should be "dummy" windows or "special" windows

because I'd like to eliminate the differences between GDI and DirectX development and I don't think we should go into the direction we currently are going, which is, that we won't have HWND and windows anymore in future GUIs

with b) it would also allow us to do things like "Invalidate" calls or handle WM_MOUSEOVER or WM_MOUSEOUT for a button even tough it is painted directly onto its parent without being a traditional window with its own DC

[DarranRowe]

OK. Let's be more specific.

a) IDXGISurface1 has GetDC and ReleaseDC members. What this does is gives you a HDC to a DXGI surface that allows you to draw to it. As to what counts as a surface, any buffer from the swap chain (GetBuffer) or an ID3D11Texture2D without mipmaps should be good enough, as long as they were created with GDI compatibility.
b) The way it currently works is that the DXGI swap chain is the link between Direct3D and a HWND. Also, as mentioned, the swap chain doesn't have to be associated with a top level window. This means two major things. First, to associate Direct3D drawing to a HWND, all you have to do is create the swap chain with a HWND and size it appropriately. Second, since the HWND associated with a swap chain doesn't have to be a top level window, drawing to children is perfectly fine.

As an example of this, suppose you have a dialog box with 3 buttons and a text box. This is a total of 5 HWNDs, the top level window and 4 children, three of which are buttons, and one is a text box. It is possible to have 5 separate swap chains, 4 of them targeting the child windows. To reiterate, you can draw to a child HWND just by associating a swap chain with that window. So no, child controls don't have to be painted directly on the parent. They can be drawn to separately.

[meirumeiru]

so... you say it's possible (inside my "dialog" class which paints it's background with Direct3D) to do something (create a swap chain or whatever) so that a child window (a control) that I created with "CreateWindowEx(L"BUTTON", ...)" (the old button from Windows 3.0 or something) will paint onto this swap chain-dc when it calls "BeginPaint"??

[DarranRowe]

It is possible with some work. However, since the window respects WS_CLIPCHILDREN, even if you are drawing the main window using Direct3D, then I would question if it is really worth the effort.
UIs tend to be relatively low performance. The redirection bitmap that GDI uses to get what is drawn into DWM performs well enough for UI drawing. If you wanted something for high performance drawing, then you would prefer to cache the UI elements in a bitmap and just transfer that.

[castorix]

so... you say it's possible (inside my "dialog" class which paints it's background with Direct3D) to do something (create a swap chain or whatever) so that a child window (a control) that I created with "CreateWindowEx(L"BUTTON", ...)" (the old button from Windows 3.0 or something) will paint onto this swap chain-dc when it calls "BeginPaint"??

If I do a test with Direct2D and CreateSwapChainForHwnd and some animated sprites, then I create a Button with WS_EX_LAYERED, it is drawn over the SwapChain :