VLC for the new Windows 8 User Experience ("Metro")

Re:VLC for the new Windows 8 User Experience ("Metro") by PaulHoule on Monday December 10, 2012 @08:29PM (#4902617)

Async comm is relatively easy to deal with in the context of media players than it is in other applications because in media players there is a fairly direct flow of information from a file or a network connection to the video and sound subsystems.

If you're building the kind of app I was building a few years ago, such as semantic graph editors, where a change in one UI element might have effects that propagate to other UI elements in an uncontrolled way, then, yes, the async comm in Windows 8 (the same problem that exists in Javascript, Flex and Silverlight) requires you to have a systematic approach to how information gets into the app.

(One thing I'd definitely note is that the Windows 8 apps like "Photos" and "Mail" are really a joke when you compare them to the Windows 7 era "Windows Live Essentials", which are really competitive -- Windows Live Essentials can handle mail spools on my crappy 2GB shojou netbook that destroy Thunderbird on a 32GB machine. My experience is that async I/O sets an upper limit on the complexity of what you can do)

VLC will have the option of bending their UI to be something that fits the Metro mold easily, so async I/O and comm should not be such a big deal.

[ Parent | on HN ]

Re:VLC for the new Windows 8 User Experience ("Metro") by Todd on Tuesday December 11, 2012 @01:18AM (#4903316)

You make a good point about the linear flow that's typical in media players. I haven't looked at the VLC source, so I'm not sure about how it's structured. With 7M LOC, I'm guessing that there might be some entanglements. The async model causes the async pattern to propagate all the way up the call chain. The I/O and other async dependencies would have to be decoupled from the gcc library to minimize impact on the existing code base.

[ Parent | on HN ]