DIB Engine, some summarization

richardvoigt at gmail.com richardvoigt at gmail.com
Thu Feb 15 18:11:14 CST 2007


On 2/12/07, Daniel Remenak <dtremenak at gmail.com> wrote:
> On 2/12/07, Stefan Dösinger <stefandoesinger at gmx.at> wrote:
> > Am Montag 12 Februar 2007 19:54 schrieb Daniel Remenak:
> > > On 2/11/07, Damjan Jovanovic <damjan.jov at gmail.com> wrote:
> > > > What about the case where you draw with GDI, then render with OpenGL
> > > > on top of that, then draw on top of that with GDI, then swap buffers?
> > > > If you draw only client-side, you have to copy to the server, then
> > > > copy back, then copy to the server *again*. You have to upload or
> > > > download the image *every time* you go between OpenGL and GDI drawing,
> > > > whereas when you draw with X11, there is no uploads/downloads unless
> > > > you use DIB sections and draw directly.
> > >
> > > Not that it's relevant to this conversation (since wine needs to
> > > support legacy apps), but just so you know, even Microsoft no longer
> > > supports this sample scenario.  Drawing with GDI over OpenGL (or DX),
> > > and reading from the GDI buffer on a hardware-accelerated window, are
> > > both undefined (officially "not supported") operations on Windows
> > > Vista.  Caused a ton of problems for my company's product
> >
> > So IDirect3DSurface9::GetDC does not work any longer? (Or
> > IDirectDrawSurface7::GetDC)
> >
> > /me parties!
> >
> >
>
> Unfortunately, no; it looks like you can still render GDI onto a DX
> surface, just not directly onto a window which is also being rendered
> to by DX.
>
> >From the linked blog article:
> "Note that there is an alternative that can often work for an
> application -- DirectX is capable of handing back a DC to a DirectX
> surface, and applications can perform GDI rendering to that DC.  From
> the DWM's perspective, that DirectX surface remains purely rendered by
> DirectX, and all is well."
>
> --Daniel Remenak

This sounds like a really simple way to support client-side and
server-side drawing without the mixing that causes repeated network
transfers: gdi32.dll GetDC, GetClientDC, and CreateCompatibleDC would
all be done client-size, while IDirectWhatever::GetDC would return a
device context that is strictly server-side.

Does that seem reasonable?



More information about the wine-devel mailing list