Direct3D

Re: Native Direct3D and .Net Framework Graphics on the same control problem

GregDude — Fri, 10 Jul 2009 06:47:39 GMT

I had several work a rounds but ended up just drawing the few extra GUI elements I needed using D3D.

Re: Native Direct3D and .Net Framework Graphics on the same control problem

legalize — Tue, 07 Jul 2009 05:10:52 GMT

You don't say anything about how dynamic this GUI stuff is that you're trying to draw with .NET, but if its relatively static I would just draw it to an image and then use D3D to combine it with the 3D stuff by treating it as a simple quad textured with the image drawn by .NET.

Either that, or do the reverse: draw the D3D stuff into a plain surface which you copy into a .NET image and have .NET do the compositing.

I wouldn't try to mix presentation from both APIs. Either have D3D do the presentation (which means rendering .NET into an image and having D3D do the composition in the back buffer using a textured quad), or have .NET do the presentation (which means rendering D3D into a plain surface and having .NET do the composition in an image).

Re: Native Direct3D and .Net Framework Graphics on the same control problem

GregDude — Tue, 07 Jul 2009 01:07:27 GMT

Thanks for the info legalize. I'm not actually wanting to draw to the backbuffer with GDI. I want to over-draw the fontbuffer.

The application consists of two parts, the native code accessing Direct3D to draw some polygons and the managed code using .Net Framework to overlay some GUI. The two parts don't really communicate with each other or access each others data.

There may be some way to achieve what I'm after using transparent overlayed windows. I would need to take care to prevent the GUI overdraw from triggering another repaint of the background, since it is the repaint that triggers the whole redraw in the first place. There are all kind of work arounds including rendering to textures and repainting with those textures, drawing some GUI elements in D3D itself, etc. but my current method is so convenient and keeps native and managed parts of the app separate.

Re: Native Direct3D and .Net Framework Graphics on the same control problem

legalize — Mon, 29 Jun 2009 03:11:51 GMT

Mixing GDI and Direct3D is supported, but its somewhat painful. You have to make sure your back buffer is compatible with GDI and you have to use IDirect3DSurface9::GetDC to obtain a compatible DC for drawing on the back buffer surface. The restrictions imposed by this model are documented on the reference page for IDirect3DSurface9::GetDC.

In Vista, GDI is implemented completely in software. This will continue with Windows 7 and beyond. If you need to mix GDI like operations with Direct3D, you should look at the DirectWrite and Direct2D APIs introduced for Windows 7. (They will be back-filled on Vista, once Windows 7 is released.)

Re: Native Direct3D and .Net Framework Graphics on the same control problem

GregDude — Mon, 15 Jun 2009 11:29:20 GMT

Thanks for replying Nick. I am coming to realize the two don't get along very well. It appears the GDI does some kind of internal buffering and layering which is out of sync with raw updates to the window. If it wasn't for this buffering or compositing, there should be no reason they can't work, perhaps as long as they are synchronized in some way.
I have just found however that this issue occurs only on Vista, not XP or Windows 7. I can make Vista work by setting the .exe properties Compatibility to 'Disable desktop composition'.

By the way, this application is a GUI game development tool which uses some windows to render scenes using the native game engine. You can imagine it is desirable to overlay the native rendering with managed GUI and not mix code since they aren't really related anyway.

Re: Native Direct3D and .Net Framework Graphics on the same control problem

Nick Gravelyn — Mon, 15 Jun 2009 05:41:05 GMT

Honestly I would have expected both to be broken. At the end of the day, you shouldn't be combining GDI with Direct3D on the same surface; they are two different graphics APIs which were likely never designed to be used on the same surface at the same time. You should just render your selection rectangle using Direct3D, as well as any further 2D graphics you render on top of the scene.

Native Direct3D and .Net Framework Graphics on the same control problem

GregDude — Mon, 15 Jun 2009 05:08:03 GMT

I am encountering and issue where drawing a control using both Direct3D and .Net Framework Graphics causes conflict.
Strangely enough this only occurs with Windows Vista. Windows XP works fine. Pleaes see the attached screen shots.

screen shots

This is the execution process:
MouseMove calls Invalidate() on the control.
Paint event is called.
Inside MyOnPaint(), I
1) Render 3D scene using native Direct3D, using the HWND from the control.
2) Draw a selection rectangle using Graphics::DrawRectangle()

Any Graphics::Draw functions overlay the Direct3D scene with visible bounding rectangles and trails.
The only way I can get the image to look correct is surround the Graphics::DrawRectangle with:

Point screenPoint = win->PointToScreen(Point(0,0));
graphics->CopyFromScreen(screenPoint.X, screenPoint.Y, 0,0, win->Size);
graphics->DrawRectangle(pen, rectangle);
graphics->Flush(Drawing::Drawing2D::FlushIntention::Sync);

It appears the GDI or Graphics code buffers the draw commands and applies them at some point.
This flush and sync code seems to synchronize them. The Graphics functions still leave white bounding boxes.

Another alternative for me is to render the selection rectangle with
ControlPaint::DrawReversibleFrame(rectangle, Color::Transparent, FrameStyle::Dashed);
However I still need to flush and sync which drops the effective frame rate from say 200fps to 15fps.