I'm looking to create a hardware accelarated DirectX (9 at the moment) window on a secondary screen. This screen is connected to the same graphics display as the primary screen (at least at the moment).
Currently, when I try to open the window on the secondary screen based on window position or by dragging it there, CPU usage jumps by about 10%, which seems to indicate that windows is switching to a software fallback rather than the hardware accelaration.
Machine is windows XP running a NVIDIA graphics card (varying cards as this runs on several machines), with the latest driver. It's also running CUDA at the same time to produce the images if that matters. Programming language is c++, manual window and message queue creation, no tookbox used at the moment to manage the GUI
Thanks
When you call CreateDevice, make sure to use the index of the monitor you are targeting. The standard D3DADAPTER_DEFAULT value is just 0, which is the primary monitor. DirectX is a bit kludgy that way, but if the window is on a different monitor than is specified in CreateDevice, then it will silently render in a framebuffer targeting the first monitor, then buffer copy to a framebuffer on the second monitor using the OS window manager.
So, the quick and dirty solution is to use CreateDevice(1, ...) instead since that is almost always be how a dual monitor setup is indexed.
A more robust solution is to use MonitorFromWindow(hwnd) to find the monitor that the window covers the most, then iterate through available d3d adapters looking for one that returns the same monitor handle using GetAdapterMonitor(). If you have a system with more than two monitors, or if you don't know in advance what monitor you want and just have an HWND, then you need the longer method.
Related
Windows provides DRM functionality to applications that require it.
Some of them, however, have more protection than others.
As an example, take Edge (both Legacy and Chromium) or IE that use Protected Media Path. They get to display >720p Netflix content. Other browsers don't use PMP and are capped at 720p.
The difference in the protections is noticeable when you try to capture the screen: while you have no problems on Firefox/Chrome, in Edge/IE a fixed black image takes the place of the media you are playing, but you still see media control buttons (play/pause/etc) that are normally overlaid (alpha blended) on the media content.
Example (not enough rep yet to post directly)
The question here is mainly conceptual, and in fact also could apply to systems that have identical behavior, like iOS that also replaces the picutre when you screenshot or capture the screen on Netflix.
How does it get to display two different images on two different outputs (Capture APIs with no DRM content and attached phisical monitor screen with DRM content)?
I'll make a guess and I'll start by excluding HW overlays. The reason is that play/pause buttons are still visible on the captured output. Since they are overlaid (alpha blended) on the media on the screen, and alpha blending on HW overlays is not possible in DirectX 9 or later nor it is using legacy DirectDraw, hardware overlays have to be discarded. And by the way, neither d3d9.dll or ddraw.dll are loaded by mfpmp.exe or iexplore.exe (version 11). Plus, I think hardware overlays are now considered a legacy feature, while Media Foundation (which Protected Media Path is a part of) is totally alive and maintained.
So my guess is that DWM, that is in charge for the screen composition, is actually doing two compositions. Either by forking the composition process at the point when it encounters a DRM area and feeds one output to the screen (with DRM protected content) and the other to the various screen capturing methods and APIs, or by entirely doing two different compositions in the first place.
Is my guess correct? And could you please provide evidence to support your answer?
My interest is understanding how composition software and DRM are implemented, primarily in Windows. But how many other ways could there be to do it in different OSes?
Thanks in advance.
According to this document, both the options are available.
The modern PlayReady DRM that Netflix uses for its playback in IE, Edge, and the UWP app uses the DWM method, which can be noticed by the video area showing only a black screen when DWM is forcibly killed. It seems that this is because the modern PlayReady is supported since Windows 8.1, which does not let users disable DWM easily.
I think both methods were used in Windows Vista-7, but I have no samples to test it. As HW overlays don't look that good with window previews, animations, and transparencies, they would have switched each method depending on the DWM status.
For iOS, it seems that a mechanism that is similar to the DWM method is done in the display server(SpringBoard?) level to present the protected content which is processed in the Secure Enclave Processor.
Given FreeSync and GSync it is now possible that graphics card and monitor work together to support variable frame rates and control when a monitor refreshes.
My question is if with a fixed framerate monitor there is any way to do something similar in a very limited way. I would like to cause a slight delay of the vertical retrace of a monitor (via HDMI / DVI) to come in sync with an external image source.
Is this possible based on TMDS based video connections? Is this something any graphics cards exposes?
I thought scaling an application in FireMonkey should be easy as it is supposed to work an a Retina-Mac too. It seems there is some background magic which chooses another style than, but this doesn't seem to be the case in Windows.
In VCL there was TForm.Scaled which does the job (more or less).
For FireMonkey I found this Article by Embarcadero but it seems Embarcadero is not quite sure if this approach is useful as in XE5 the sampleproject "ControlsDemo" doesn't contain the scale-trackbar anymore. It also requires to have a root-TLayout present in all forms for which the scale factor can be set. I don't have such a element in my forms (and I'm afraid to add one as I cannot be sure if I run in another firemonkey bug than).
So how do I account for different DPI-Settings using FireMonkey?
Edit: I tried hacking TPlatFormWin and set CurrentScreenScale to 2 but it didn't work: I got black toolbars, but no scaling, but at least it used the HighRes alternative from the provided TImage.MultiResBitmap.
If anyone reads this... my experience with Windows desktop Firemonkey is that you have to take care of OS DPI setting manually and it's OK to put your controls in a top container (a TLayout) that's Scale is set according to the OS screen DPI settings (determined with some low level code).
However there are cases when you need to reverse this scaling - for example a Viewport3D must be scaled back 1/X to correctly show inside the scaled up container. Otherwise pixel level artifacts will show, image quality will be awful.
This scale up/scale back technique works nicely.
U can do something like this to change the root TLayout:
with 100 being the default
if windowsscale>0 then begin
LayoutScale.height:=ClientHeight*100/windowsscale;
LayoutScale.Width :=Clientwidth*100/windowsscale;
LayoutScale.Scale.X:=windowsscale/100;
LayoutScale.Scale.Y:=windowsscale/100;
end;
Is there any way to control more than one mouse, the first act as usual mouse while other would be treated as digitizer input. The problem is How to register each mouse to be treated differently and how using mousehook without capturing the whole mouse event.
I haven't write any code yet on this project, and I 'am just starting with collecting information and stuck with theses questions. I'm going to use Delphi 7
I do not know anything about it, but Multi-Touch Vista at CodePlex adds support for multiple mice.
Multi-Touch Vista is a user input management layer that handles input from various devices (touchlib, multiple mice, TUIO etc.) and normalises it against the scale and rotation of the target window. Now with multitouch driver for Windows 7.
http://multitouchvista.codeplex.com/
I am trying to capture DWM's DirectX surface by using DXGI and GetDisplaySurfaceData() using Direct3D 10/11.
However, when I am taking ownership of the adapter's output with IDXGIOutput::TakeOwnership() before calling to GetDisplaySurfaceData(), the whole screen blacks out for a moment and then restores back (just as during display mode switching).
Why does this happen, and how can I prevent this?
I know this is extremely late. But for what it's worth, the documentation explicitly says that you are not supposed to call TakeOwnership() directly as the results will be unpredictable.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb174558(v=vs.85).aspx