Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WinRT demystified

tirania.org

Post reply on HN
Print view View original

41–48 of 48 posts

Re: WinRT demystified

#41

Post by nxn »

kevingadd wrote: post #29
rwolf wrote: post #27

and Javascript uses promises and "then ()". What is "then ()"? Have they created their own wacky fork of Javascript? Javascript already handles asynchronous programming (feel free to argue that is doesn't do it "right" or even "well"), so why extend the language?

It's a method with a signature like this: promise.then(callback) so: var p = doSomethingAsync(); p.then(function () { alert("hello"); })

I'm assuming they only chose to use this pattern for the purpose of keeping function/method signatures as uniform across the languages as possible? I can't see another advantage to this in JS. Seems like all it's doing is wrapping the call to the actual async operation within the 'then' function, and then probably using the callback as the last argument or storing it somewhere where it will be accessible to the async operation right before it returns.

Re: WinRT demystified

#42

Post by beagle3 »

jbk wrote: post #40
beagle3 wrote: post #22

Earlier quoted context omitted.

I'm developing an app for surveillance that talks to multiple IP cameras and microphones. We made the unfortunate choice of C# early on. - no normal RTSP support. Ok, I used libav (working hard to wrap it, cause it's a well written C library, but not trivial to use from C#) - I get h264 frames that I need to look at before decoding. No way to give compressed h264 frames to WPF to decode. (So I use libav again). Silve…

Use libVLC.Net :D You get correct RTSP support, h264 decoding, hardware acceleration for decoding, DirectSound audio output and resampling.

I looked at it, but it didn't appear that libvlc gave me the level of control I needed (frame accurate seeking and reporting, access to framebuffers, stuff that low-level). Perhaps I didn't look closely enough...

Thanks for VLC, btw! It's awesome!

Re: WinRT demystified

#43

Post by beagle3 »

chucknthem wrote: post #39

"You might be thinking that you can use some trick (referencing the GAC library instead of the compiler reference or using reflection to get to private APIs, or P/Invoking into Win32). But all of those uses will be caught by AppStore review application" I'm curious to know, how will the review application be able to catch your use of the private API through reflection? It seems like a pretty hard problem that could b…

I don't know, but it just _might_ be time for Microsoft to do jail-style security, in which you can't actually reflect from libraries you have no permission to.

Re: WinRT demystified

#44

Post by beagle3 »

gecko wrote: post #36
beagle3 wrote: post #22

Earlier quoted context omitted.

I'm developing an app for surveillance that talks to multiple IP cameras and microphones. We made the unfortunate choice of C# early on. - no normal RTSP support. Ok, I used libav (working hard to wrap it, cause it's a well written C library, but not trivial to use from C#) - I get h264 frames that I need to look at before decoding. No way to give compressed h264 frames to WPF to decode. (So I use libav again). Silve…

Just to clarify: my "it appears to be there" was in reference to the WinRT-powered DX11.1 in Windows 8. Your experience sounds exactly like why I wouldn't be doing anything vaguely low-level in C# in Windows 7 or earlier.

And you're comment is exactly why I wouldn't do it in Windows 8 either.

There hasn't been a single time when the answer to some deficiency was not "Well, this version of Windows/.NET is cr*p, but the next one is going to be perfect for every need".

I didn't choose to go with C# for this project - someone else did. Being the low-level guru, I was called in to fix all the deficiencies.

Really, .NET has been out for 10 years now, WPF for 5. There is no excuse for this abysmal level of support, and until I see Win8 actually working properly with sample code that addresses stuff such as I mentioned above, I won't consider it.

Re: WinRT demystified

#45

Post by beagle3 »

kenjackson wrote: post #37
beagle3 wrote: post #22

Earlier quoted context omitted.

I'm developing an app for surveillance that talks to multiple IP cameras and microphones. We made the unfortunate choice of C# early on. - no normal RTSP support. Ok, I used libav (working hard to wrap it, cause it's a well written C library, but not trivial to use from C#) - I get h264 frames that I need to look at before decoding. No way to give compressed h264 frames to WPF to decode. (So I use libav again). Silve…

Sorry. That sounds like something meant for C++. Most of this sounds like pretty key stuff like the timer. Didn't anyone do a basic proof of concept first to flush this stuff out? Just curious.

Yes, they did a proof of concept using the MediaElement, with windows driven playing -- that actually works. And they assumed that fine timing control, different codecs, frame accuracy etc would be available if needed.

I agree it's meant for C++ on Windows (if it is meant for Windows at all - the 15ms timer precision thing runs so deep it bites in many places you wouldn't expect).

But Microsoft and MS fanboys keep touting that "C# is all you need to get things done" - that has never been the case, and I expect it not to be the case with WinRT either.

Re: WinRT demystified

#46

Post by beagle3 »

pcj wrote: post #34
beagle3 wrote: post #22

Earlier quoted context omitted.

I'm developing an app for surveillance that talks to multiple IP cameras and microphones. We made the unfortunate choice of C# early on. - no normal RTSP support. Ok, I used libav (working hard to wrap it, cause it's a well written C library, but not trivial to use from C#) - I get h264 frames that I need to look at before decoding. No way to give compressed h264 frames to WPF to decode. (So I use libav again). Silve…

Yeah, that doesn't fun at all. Just curious though, would these new API's [ http://msdn.microsoft.com/en-us/library/windows/apps/windows... ] address your scenario?

Probably not. I need frame-by-frame timing control. These APIs don't seem to deliver anything previous APIs didn't - just make it a little easier to use.

Re: WinRT demystified

#47

Post by beagle3 »

synacksynack wrote: post #38
beagle3 wrote: post #10

Does anyone know if it will have a Sound API? .NET still doesn't. Neither does it have usable Direct{3D,Sound,X} binding.

There seems to be a lot available for multimedia with C++. http://msdn.microsoft.com/en-us/library/windows/apps/hh45275...

Might be useful, but I'm not holding my breath. I have to deliver in a couple of months.

Re: WinRT demystified

#48

Post by jbk »

beagle3 wrote: post #42
jbk wrote: post #40

Earlier quoted context omitted.

Use libVLC.Net :D You get correct RTSP support, h264 decoding, hardware acceleration for decoding, DirectSound audio output and resampling.

I looked at it, but it didn't appear that libvlc gave me the level of control I needed (frame accurate seeking and reporting, access to framebuffers, stuff that low-level). Perhaps I didn't look closely enough... Thanks for VLC, btw! It's awesome!

frame accurate seeking should be there, but no reporting, true.

If by access to framebuffers, you mean getting the raw images in a buffer, yes you can.

Post reply on HN