Went back to my last blog (on http://rrelyea.spaces.live.com/blog) to look at other entries in my Software Should series.
Was interested to recently see Soluto’s approach to keeping its aspect ratio fixed, but scaling to any size requested to the user.
WPF team is busy working on digging into our most frequent 4.0 crashes right now…
I’ve recently explored using XAML to write down UserSettings recently in “Persistable View Models & XAML for Config”
Just ran into another piece of software that triggered one of my pet peeve’s. Was installing Evernote since Rudi Grobler’s “Week of <XAML />” day 0 talk listed it as the 1st WPF example app.
The setup program’s last page includes a checkbox which only works if you click on the “box”.
I hate that! Please stop!
Advertisement
Our WPF and Silverlight UI Frameworks make it hard to make this mistake…since <CheckBox>includes a label</CheckBox> automagically.
However, TextBoxes with Labels aren’t automagic. I’d like to see FxCop for XAML rules enforce things like that… (realizing a big benefit of Declarative UI…)
Posted a slightly enhanced code drop for video wall (see link to .zip on http://robrelyea.com/demos/videowall):
- Took advantage of the fact that ViewportWindow can take a UIElement, not just a MediaElement, as the “masterElement”. Built a context menu option to switch to VectorScreen mode. Reviewing with David Teitlebaum and others on the team, but still appears to not be software rendering, even for the large vector rendering (16,000x8,000)…
- App.xaml.cs – refactored the creation of MediaElement into MediaScreen.xaml and greatly simplified OnStartup() grokability. Also enabled switching to VectorScreen.xaml as masterElement.
- ViewportWindow.xaml.cs – exposed ability to set MasterElement in method after window creation.
- …
Here is a picture of a dual monitor setup. I’ve manually maximized the first screen window, and showed how you can create and arrange several windows on any part of your desktop, and the live video shows up there.
David, a WPF/Silverlight graphics PM, did a short write-up recently on some tips that he has shared with customers doing VideoWalls.
WPF applications can only run with hardware acceleration when their window's size does not exceed the maximum texture size allowed by the machine's video card (typically 4k x 4k or 8k x 8k). This is not normally an issue when running applications on a typical monitor, but when running applications whose windows span multiple monitors, it is very easy to resize the window so large that the maximum texture size is exceeded.
One way to work around this, and allow a single application to span multiple monitors without falling back to software rendering, is to create a separate window for each monitor. Each window can be dragged to the appropriate monitor and maximized to fill the whole monitor. Depending on the type of content to be displayed, getting your application's content to span multiple monitors can be as easy as filling each window with a visual brush displaying some section of your overall application. This may not work well for all content types, and will not allow for interactivity as it's a visual brush, but for a large class of display-only solutions including video walls, this can work well.
Initial sample (and future enhancements) can be found here: http://robrelyea.com/demos/videowall
Sample overview:
The basic idea is to create one MediaElement and create n ViewportWindows, which split amongst monitors, or not, show a segment of the video by rendering a visual brush of a segment of the MediaElement.
I’ve taken David’s initial technology example, and evolved the API/factoring a little bit.
The user of each ViewportWindow can right click to load a new video, pause/resume, create a new window, close window, and exit the application. Each of the ViewportWindows can be dragged and dropped via the small square in the upper right of the window.
My guess is that there are several enhancements that we’ll be able to do to this…hope it is helpful.