It isn't fair for me just to pick on other peoples' UIs, so time for an example from my own program.
Rolling a configuration dialog by hand isn't a lot of fun. You need to code at least two paths for data, one going into the dialog controls, and another going out; if the settings are persistent, you need another two paths to and from the Registry or some other backing store. Also, typically not all controls are pertinent for all configurations, so additional logic is needed to track changes and enable or disable controls as needed. Finally, the settings in the dialog need to be validated against acceptable bounds for each datum. This adds up to a lot of code, which makes it annoying to add features to the existing UI, and I've been working on ways to reduce this. One such way is to implement "data exchange" routines that can either read or write data to a particular store; this then reduces the number of places where you have to keep track of variables, UI control IDs, etc. for each dialog.
The "resize" video filter has been in need of an overhaul for a while, so I decided to add some needed features and use it as a test bed for some of the new methods. Unfortunately, wrapping methods alone isn't enough to cure some of the usability problems that cropped up.(Read more....)
I don't write very fancy UIs; those of you who use my program probably already know this. The main reason for this is that I tend not to put a whole lot of time into making them fancy, because for me it has a low return for the amount of time I have to invest in it. Also, I'm not interested in spending a whole lot of CPU power on one either — why slow down a capture or a render with a UI that takes a lot of clock cycles to redraw? I do have one rule about UIs, though, and that's to use combo boxes very sparingly. Preferably not at all in new UI. Combo boxes take too many clicks, since you have to either waste a click for the drop-down or drag awkwardly X11-style, and I find that listboxes or lists of options look better and are easier to use. That's why in most of VirtualDub's more recent dialog, you see a lot of option sets instead.
And then, in the .NET Framework WinForms library, there is... the property grid.
A property grid is a generic UI widget that displays lists of properties, which can have values of type text, boolean (true/false), or even custom ones like colors. Properties can be separated into groups, and there are buttons to allow the user to sort the list of properties. There is also a pane at the bottom that holds help text for the property.
After using several .NET WinForms-based programs that use property grids, I've now come to a conclusion: I hate property grids. I hate them enough that I think they deserve a Joel Spolsky level rant and should be abolished from production UI.(Read more....)
New stable version is out, 1.6.14, which is just 1.6.13 with a few minor fixes and changes. For the most part creating this version was uneventful, except for the part where I coded a genetic algorithm to produce a Huffyuv frame that had a value encoded on the last DWORD of a frame that was exactly (multiple of 16K) - 32 bytes in size. I had to do this in order to replicate and verify a workaround for the random Huffyuv crash, which is caused by VLC decoding reading four bytes beyond the end of the frame.
Also, after another report, I tracked down the cause of the "vidc.draw" crash, where VirtualDub crashes trying to open an AVI file or bring up the video compression dialog on a codec with FOURCC "draw." Well, rather, I found a page on the Adobe Premiere Elements technical support site through Google that explains the problem. Basically, the crash is caused by the addition of a video codec entry in the Registry that has a space at the beginning of the filename. The behavior of the OS in this regard is rather strange — an attempt to open such entry with ICOpen() succeeds with a valid HIC, even though the codec filename is invalid, but any calls using that HIC crash in ICSendMessage(). I didn't put in a workaround for this, because it's unclear how to safely to do, but deleting the errant entry resolves the problem, and doing so can't make the problem any worse since whatever registered the bad entry obviously isn't using the codec that was supposed to be registered.(Read more....)
However, in VMR7/9 mode when not using the overlay and using a YUV output mode, both ATI and NVIDIA seem to output a luma range of 16-235, which is a pain considering the monitor works in rgb where the luma range is 0-255, requiring either a software conversion to 0-255, or to specifically adjust the hardware color controls to compensate.
The VMR7/9 being referred to are the DirectShow Video Mixing Renderers, which are filters that render final video on the screen in a player like Windows Media Player. YCbCr data, which is frequently 8 bits per channel, nominally has a range of 16-235 for the luminance (Y) channel, where 16 represents black and 235 represents white. Any values outside of this range are reserved; the usual way of handling them is to clamp to the valid range. This is sometimes a point of confusion because JPEG JFIF specifies a slightly different encoding where YCbCr values are encoded with the full 0-255 range; mixing these up causes contrast shifts in the video. Some Motion JPEG codecs that don't properly compensate for this difference when exchanging the output of the JPEG engine with client applications can trigger this. It sounds like a similar mixup is occurring here, in that 16-235 data is being displayed as if it were 0-255, resulting in a 14% loss of contrast.
What's odd about Blight's statement, though, is that VMR7 and VMR9 are quite different beasts — VMR7 is DirectDraw 7 based, whereas VMR9 is Direct3D 9 based. It's somewhat unusual to see the same bug in both. I was curious, so I decided to look into it.(Read more....)
Ever tried to do something with a video player, and gotten a fluorescent green or purple blotch where your video was supposed to be? Like take a screenshot, move it to a second monitor, or show it on TV out?
This is caused by the use of a hardware video overlay. This is a second video screen that is overlaid over the primary surface by the video hardware. Because the two are only generated at scanout, and even then sometimes only on the primary monitor, attempts to capture the video by screen capture will just give you the underlying window instead, even though you can see the video just fine.
The easiest way to work around this problem is to change the video acceleration options for your video player to use a lower setting, which usually disables use of the video overlay. A few applications, most notably DVD players, won't let you do this, in which case you'll either need to find a screencap application that hooks DirectX, or loop TV out into a video capture device, assuming your video card can display the overlay on TV out (some can't, or don't when the TV is the secondary monitor).(Read more....)