>I dont think they are handled even in the original WinVNC code. I have no
>idea about DirectX api but I think the same idea can be used by wrapping the
>appropriate DLL.
They are sorta handled, the same way everything else is handled. If you
GetDC(0), you have the device context for the screen - ie, the actual video
RAM. DirectX DCs still go to the video RAM, so if you poll pixels out of
the full screen DC, you also cover DirectX operations. It's terribly slow,
but I have run programs that use DirectDraw, Direct3D, and even OpenGL
acceleration through VNC. As I said, polling can still be used for those
programs until wrapper can be written for those interfaces. A GDI wrapper
would catch 99% of all normal intended uses of VNC, and would be so much
faster than the current approach.
DirectX is COM based, which means you would have to register your own COM
component with the same GUID. But if you did that, you would be unable to
get to the original COM component. You *might* be able to wrap the 4 or 5
normal DLL entry points and do some pass through tricks, but I think it
will be much harder than doing so with straight DLLs. That's why I don't
want to see effort that could be spent getting a working GDI wrapper spent
on DirectX stuff. Get the biggest payoff with the least effort whenever
possible, right?
_____________________________ /"\
Mac Reiter \ / ASCII Ribbon Campaign
Nomadics, Inc. X Against HTML Mail
[EMAIL PROTECTED] / \
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
