Implications of Full-Screen Support for the Application (Windows Embedded CE 6.0)
1/6/2010
Although the interface exposed to applications is relatively simple, the underlying implementation can be more complex.
The full-screen renderer has some special properties that application developers should be aware of. In particular, the renderer changes display modes only when activated (either paused or running).
Therefore, if the filter graph is stopped when switching to full-screen mode, no change might be obvious until the filter graph is started again. When the filter graph is subsequently run, the display mode will change and the full-screen rendering will start.
If a window is being stretched full-screen (that is, no full-screen renderer is being used), the change will be viewable when the full-screen mode is set, regardless of state.
If full-screen playback is being supported directly by a filter in the filter graph, it might elect to copy the behavior of the full-screen renderer and switch to full-screen only when activated.
The filter supporting full-screen playback might have to do this, because the resources they require to play full-screen might not be available until then. Therefore, an application should avoid setting full-screen mode when stopped.
This makes sense in a user interface context as well, because if full-screen mode is set when the filter graph is stopped, users are unlikely to be able to start the graph running without switching out of full-screen mode (that is, tabbing back to the original application).
All renderers that implement IVideoWindow send event codes to the filter graph manager when their windows are activated or deactivated.
When in full-screen mode, the PID watches for these event codes. When it sees a window that it made full-screen being deactivated, it switches out of full-screen mode and sends an EC_FULLSCREEN_LOST notification to the application event queue.
This is the only interference caused by the PID; all other user interface is left open to the application as described in the remainder of this topic.
An important aspect of full-screen playback is that when in full-screen mode, no window can be displayed on top of the full-screen window.
In fact, when the full-screen renderer switches display modes, it disables all GDI output for other applications, so displaying a window on top of a full-screen window is impossible. Any user interaction with the computer must be done through hot keys.
Whatever mechanism the PID ultimately uses to implement full-screen playback, it always ensures that the message drain property is set on the window executing the playback. (The message drain specifies a window that will be forwarded all Windows® messages sent to the renderer.)
So, even if the full-screen renderer is used, as long as a message drain has previously been set on the filter graph manager's IVideoWindow interface, all messages will be passed on to that renderer.
Because the message drain is set on the appropriate window, an application can rely on receiving all mouse and keyboard messages when in full-screen mode, regardless of which filter is implementing it.
An application can use this fact to implement hot-key support for seeking, for example. However, properties can be set only when not in full-screen mode, so if the only time an application is required to catch messages is when it is in full-screen mode, it must set the message drain before setting full-screen on.
Likewise, the message drain can be reset only after setting full-screen mode off.
One other application consideration is that, when in full-screen mode, any source and destination rectangles set through IBasicVideo will not be adhered to.
The PID resets these rectangles when switching to full-screen mode. It does this because not all filters implementing full-screen support can guarantee to support IBasicVideo as well.