It's an interesting topic.
It depends on Windows version.
Up to Windows XP with XPDM driver model under the hood, each monitor was counted as separated 'devices' (say, GPUs), even if they were attached to the same video card (adapter).
If you rendered something on device1 and blitted (copied) the result to the window (that's how windowed ddraw works) residing on the output of device2 then it meant a slow copy because the bitmap had to be copied back to system memory first (slow) to be able to copy it to the display memory of the other device (remember the slow window content moving on Win3.1?).
DDraw had 2 choices here: either do the slow copy or just clip the destination rectangle with the display rect of device1 and neglect device2.
This was an issue even with D3D8/9. As far as I remember they just neglected parts of the window that didn't belong to the presenting device.
Even Media Player, using hw acceleration on DX9, did this. It could switch between devices dynamically though, according to which one contained the largest part of the output window, and leaving black the rest.
(I worked for a company and had to implement full hw acceleration for the windows of a certain application. This was in the XP era, and requirements for the user experience didn't allow to just come up with a lame solution, so the implementation wasn't simple.)
But when Vista was released with the WDDM driver model then it all changed.
Term of traditional device was replaced with adapter and the driver model fully supported sharing videomemory between them. That's what the desktop compositor needed, since that's a DX application itself. Internally DX8/9 was remapped to the new driver interface, so this window-problem disappeared and the new functionality was even available through D3D9Ex.
DDraw might have been untouched and still clips to its own device, so it may be normal. I don't really know.
