I have a C++ application that uses the Win32 API for Windows, and I'm having a problem with GDI+ dithering, when I don't know why it should be.
I have a custom control (custom window). When I receive the WM_PAINT message, I draw some Polygons using FillPolygon on a Graphics device. This Graphics device was created using the HDC from BeginPaint.
When the polygons appear on the screen, though, they are dithered instead of transparent, and only seem to show few colors (maybe 256?) When I do the same thing in C# using the .NET interface into GDI+, it works fine, which is leaving me wondering what's going on.
I'm not doing anything special, this is a simple example that should work fine, as far as I know. Am I doing something wrong?
Edit: Nevermind. It only happens over Remote Desktop, even though the C# example doesnt Dither over remote desktop. Remote Desktop is set at 32-bit color, so I don't know what's up with that.
Hmm... The filling capabilities are determined by the target device. When working over remote desktop, AFAIK Windows substitutes the display driver, so that can change the supported features of the display.
when drawing on wm_paint, you actually draw directly on the screen surface, while .net usually uses double buffering (draws to in memory bitmap and then blits the entire bitmap)
there are some settings in gdi+ that affect the drawing quality. maybe there are different defaults for on-screen, off-screen and remote painting?
It only happens over Remote Desktop
Many remoting applications will reduce colour depth in order to reduce bandwidth requirements. While I haven't used Remote Desktop, the same happens on certain VNC connections. I'd check your RD server and client settings.
Related
I have a desktop application where all windows (HWND) render itself with Direct2D 1.1. My question is how to do it more correctly?
Should each window has its own Direct2D device context derived from one Direct2D device? In this case, I cannot render transparent content on a child window without additional tricks (I have to change target on parent window’s context, render parent window to Direct2D bitmap and then draw this bitmap on child’s target).
May be it is better to have one Direct2D device context where all windows render itself? I believe DirectComposition works in a similar way. Unfortunately, I cannot use it because I target Windows 7.
You're asking a question whose answer will be very application specific. I recommend avoiding the whole problem of trying to get HWNDs to render with transparency amongst each other, especially if you're throwing Direct2D into the mix. There is just too much pain in that direction. Every version of Windows that you support will have different bugs that you'll be constantly bumping into and grasping at workarounds for.
Case in point: For the v4.0 release of Paint.NET, I converted all text rendering to DirectWrite, and almost all UI controls to use Direct2D. The image thumbnail control at the top of the window (the MDI selector) is using Direct2D for rendering but it also has to compose on top of what's behind it. And it has to play nice with glass on Win7 (it looks great though!). The code for this is awful, tricky, barely maintainable, and it seems to bump into a different rendering bug on every release of Windows: 7, 7 SP1, 8, 8.1, and 10 all behave slightly differently! It's really annoying to test, too; it's the only reason I have to set up and maintain VMs for every version of Windows that I support (other than the installer and updater). Windows 7 worked fine, then 7 SP1 added a bug which required some tuning to how I filled the alpha channel. Windows 8 has flickering when you resize the window unless I do a certain hack, but 8.1 works fine. 10 then has its own flickering bug if software rendering is used. Remote Desktop breaks things in its own way. Then you also have to worry about High Contrast, and whether DWM is enabled/disabled if you're supporting Windows 7. They all behave differently and it's really really painful.
Anyway. What you seem to really need is a UI system like WPF or XAML which doesn't use anything other than a top-level HWND container. At that point you're custom rendering everything and doing your own hit-testing and input routing (and accessibility and all sorts of other things), so it's not a small task.
Regarding the "how to do it more correctly" question and cardinality of device and device context: Have you thought about just using ID2D1Factory::CreateHWNDRenderTarget or ID2D1Factory::CreateDCRenderTarget ? They return ID2D1RenderTarget but you can call QueryInterface to cast them to ID2D1DeviceContext (this fact is missing from the docs but is also clearly intentional). This should simplify working with Direct2D and HWNDs quite a bit. This is what I do in Paint.NET: I still use an HWND for each control, but each control is using its own HWND or DC render target. If you're willing to poke around with Reflector or ILSpy, checkout Direct2DControl and Direct2DControlHandler in the Paint.NET DLLs.
Also, be careful about using more than 1 hardware accelerated HWND render target. You don't want to get into a weird area where every Direct2D-based UI control is waiting on VSync. Using D2D1_PRESENT_OPTIONS_IMMEDIATELY when creating the HWND render target should help. DWM already handles VSync, so you should be fine to tell Direct2D to ignore it unless you're doing some rather specific stuff with animations and timers.
I want to draw a small dot at the center of the screen so that it must remain after running of any application. A dot should stay even after I launch an application in full screen mode. Like a dead pixel.
I have already installed Visual C++ on my computer with Windows 7. I have some experience with C++, but I never worked with graphics under Windows OS.
How can I draw a dot on a screen?
Many graphics cards have overlay features, and it is likely possible to set one up to be foremost on the screen regardless of what other applications are rendering in other layers.
But the method to do that would be specific to the video card model and driver.
Or, you can try to get your code inside the application doing full-screen rendering, find their rendering context, and draw to it at the ideal time. Which still requires a bunch of variants for all the different graphics APIs.
Here is someone who describes Steam's attempt to solve the portability issue (with a zillion implementations) and how to take advantage of that.
I would create a properly positioned 1x1 pixel (or whatever size you need) window with no borders or title bar, all client area and paint it appropriately. It's important that the window is created with the WS_EX_TOPMOST style. As long as your program is running, the window will be visible as long as there are no other windows with that style overlapping it.
I've done this as a prank. It worked really well over a full-screen OpenGL game (Quake III). I installed it on a friend's machine so that it would flash the word LOSER! in big letters in the center of the screen at random times during the game.
This worked perfectly well on an XP system. I imagine it should work on Windows 7.
let me first specify my development essentials. I am writing an Windows DLL. The programming language i do focus on is C/C++. Asm blocks are possible aswell when required for my task. Maybe even a driver, but i do not have any experience with them at all.
The DLL is being injected into a host process. That's always a Directx environment. Either Dx9, Dx10 or Dx11 and may run in fullscreen or windowed mode.
The method should support windows xp up to windows 7 and is being compiled in x86 only.
The goal is to come up with a function taking a screenshot of a given process-window. The screenshot is never being taken from the host process itself. Its always another process! The window may contain directx or gdi32 content. Maybe other contents are possible i do not think of at the moment (windows forms comes to my mind. i am not sure how that is being rendered internally). The windows may be minimized.
That screenshot needs to be accessable/convertable to an directx texture such as Texture2D, depending on the Directx environment i am working in. Saving the screenshot as an png/bmp is enough thoe, as i do know how to create such a texture from memory.
I've already tried the oldstyle BitBlt way, that didnt work on minimized applications thoe. The minimized applications are being drawn, when i send WM_PAINT messages to the targeting window. That aint a solution for me, as i also need to keep up with directx applications which doesnt react to such messages.
Maybe i need to hook each single DirectX window to accomblish my task, to access the backbuffer directly, i do hope for some better methods anyways.
For the reason that i do take a lot of screenshots from multiple windows, i would like to implement a fast method, which isnt such a cpu bogus. Copying from VideoRAM may be a bad way to go when having such performance needs.
I do hope for some ideas, maybe code samples as i am not familar with all the possibilities i could go for. I've looked at some windows thumbnail api, but that didnt support xp from what i could read.
Thanks in advance,
Frank
I would like a win32 program that takes the desktop and acts like it is shattering glass and in the end would put the pieces back together is there way reference on Doing this kind of effect with C++?
I wrote a program (unfortunately now lost) to do something like this a few years ago.
The desktop image can be retrieved by creating a DC for the screen, creating a compatible bitmap, then using BitBlt to copy the screen contents into the bitmap. Then use GetDIBits to get the pixels from this bitmap in a known format.
This link doesn't do exactly that, but it demonstrates the principle, albeit using MFC. I couldn't find a Win32-specific example:
http://www.flounder.com/screencapture.htm
For the shattering effect, best to use Direct3D or OpenGL. (Further details are up to you.) Create a texture using the bitmap data saved earlier.
By way of window for associating with OpenGL or D3D, create a borderless window that fills the entire screen and doesn't do painting or background erasing. This will prevent any flicker when switching from the desktop image to the copy of the desktop image being used to draw.
(If using D3D, you'll also find GetMonitorInfo useful in conjunction with IDirect3D9::GetAdapterMonitor and friends, as you'll need to create a separate device for each monitor and you'll therefore need to know which portion of the desktop corresponds to that device.)
On Windows (Vista32), I want to display some simple graphics on top of a fullscreen flash window (an overlay of useful information while using the flash application). What's the fastest way to accomplish it?
I think I may be able to achieve it using DirectX with the DDSCAPS_OVERLAY flag but with the only example I've found I get an exception:
E_NOTIMPL
The function called is not supported at this time
on
m_direct_draw->CreateSurface(&ddsd, &m_overlay_surface, 0)
(full code here: http://nexe.gamedev.net/files/Overlay-2005-11-21.zip)
Something relevant to C/++ or Python would help me. I'm using the latest DirectX SDK.
Thank you
Just create a Layered Window and draw to it with an alpha channel - in WPF, this is as easy as setting the AllowsTransparency bit on the Window
While the transparent layered window is useful, it doesn't appear on top of the fullscreen flash with WS_EX_TOPMOST set.
Note sure how to reply to Paul sadly.
Overlaying on a 3D fullscreen application is very relevant but while it works and flash appears to load dx9, it doesn't show on flash.