Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

AndyC AndyC
  • What's with all the complaining about high DPI displays for Windows desktop?

    Sure, if you take the Apple approach and only support pixel resolutions that are exact multiples, it's an easier problem to solve. Windows has to support just about any resolution and pixel density you throw at it and still work because there are lots of devices and use cases out there where people have or need other resolutions. Not to mention that it's a pretty crappy solution anyway, text gets sharper but everything else just starts to look blocky and wastes the sharpness of the display (which is why apps tend to have their UI redone to work on retina iPad etc).

    And which Windows editions (other than Server where high dpi is mostly a non issue) aren't intended for movie watching?

  • Italian spyware on all phones but Windows?

    , GoddersUK wrote

    *snip*

    How? Yes, in limited circumstances, it may be understandable; heck - we all make mistakes. But in most circumstances it's a case of people who don't/won't/can't think before clicking or who don't/won't/can't spend 5 minutes educating themselves about sensible behaviour online.

    So what is that sensible behaviour? Only buy things from the app store? Doesn't work, it's malware ridden. Only trust known brands? There's way to much passing off to make that viable. Check the permissions? Basically meaningless nonsense to the average person and you can't honestly expect them to learn the ins and outs of software development just to be able to use their phone, can you?

    If you can distil the advice that guarantees safe behaviour down to as little as you can with a knife, then you're doing better than anyone else.

  • Italian spyware on all phones but Windows?

    @GoddersUK: I'm not convinced you do, people have been downloading random stuff from anywhere and assuming it's legit for years. And I'd say that's still not their fault.

    Windows, MacOS and Linux are all OS's based on an old concept of security. One where the issues were protecting the system from the users and users from each other. The world has moved on. We need operating systems that protect the user from themselves, from the applications they blindly download and run because they believe it does what it says (and only what it says). Android is doing a pretty abysmal job of that at the moment.

  • async and lock

    , BitFlipper wrote

    *snip*

    Which audio related APIs require passing along more than a few parameters like length, IntPtr etc? The whole point of the benchmark is to show the overhead of a P/Invoke call. The audio APIs are pretty simple so I don't understand your point.

    *snip*

    Correct, the intention was to make it sync, hence the lack of "...Async" at the end.

    *snip*

    DoSomething and DoSomethingAsync is purely used to show the overhead of making a non-async vs async/await call. We need to compare an async op to something. If you don't have a non-async baseline, how will you know what async adds to the picture?

    Also I have shown how the async/event pattern is an order of magnitude faster than async/await pattern. You can have IO with much lower overhead than what you can possibly get with await/async.

    I'm not sure how your conclusion is that my tests don't show anything useful.

    1) When using the audio APIs, your entire audio data has to be marshalled. PInvoke can be very efficient in some circumstances, but its not free. Trying to benchmark the impact of marshalling with different data structures will give you a false impression of the impact.

    2) Your missing the point, the inner workings of DoSomething are an inherently synchronous operation. The inner workings of audio IO are not synchronous. The compiler can do different things with your example than it can real APIs. To make your benchmark even vaguely comparable, you'd need to do something asynchronous inside DoSomething and then make DoSomething a synchronous wrapper around that.

    3) Your Async/Await example isn't calling a real Projected asynchronous API, so it's adding all the overhead of the Task class, whereas real Projected APIs use the IAsyncOperation COM interface and the Projection takes care of making it look the same to the language. Again, it's an Apples/Oranges comparison.

    You need to actually measure what you are really doing, instead of creating examples that are only superficially similar.

  • async and lock

    QueryPerformanceCounter only has to marshall a long and a bool and only in one direction, which basically amounts to no work at all. That's not meaningful in a context where you're having to marshall structured data. 

    Also "DoSomething" in your benchmark is an entirely synchronous operation, but IO on Windows is never synchronous. Any "synchronous" API call would still ultimately be wrapping an asynchronous event, that's just fundamental to how the OS works. If you're going to benchmark something, you actually need to benchmark the thing you're trying to do, not something entirely different.

  • Italian spyware on all phones but Windows?

    , GoddersUK wrote

    *snip*

    FTFY. Seriously, having a rootable phone isn't the risk; running nude-britney-spears.app is.

    There have been plenty of examples of non-porn apps in the Google Play store which are malware. Many of the deliberately designed to look and even operate like existing legit apps that are not immediately distinguishable to a non expert.

    Blaming end users for all the problems on Android is extremely unfair.

  • async and lock

    , androidi wrote

    @AndyC: You can use Wasapi in C# through the Naudio wrapper on desktop clr. I don't know if you can do that with the Phone/RT in a store app though?

     

    Wouldn't know, but the WASAPI API is available in Store apps so I guess it's possible.

  • async and lock

    , BitFlipper wrote

    *snip*

    And no-one has explained how switching to C++ is going to magically make async/await not suck for this purpose.

    Because in C++ you can just go straight to WASAPI and do low latency audio the way Windows intends you to, you get all the benefits of asynchronous calls without any overhead. Now maybe you could do the same in C# (I've never tried), but my bet is that the interop overheads are always going to be working against you when it comes to reducing latency.

    Right tool for the right job and all that.

  • async and lock

    , BitFlipper wrote

    *snip*

    So are you saying audio IO is also async?

    But that is somewhat beside the point anyway. The point is the audio paths are highly optimized for low latency, but having to start making async calls all over the place will severely impact it. Even if the audio IO is async (not sure it is since we are talking to an audio driver that has direct access to the audio hardware), then there would only be one point where it would be async per audio buffer. But if you need to start making additional async calls to process one buffer of audio, then it will be a problem for sure.

    So are you saying it is ok to make async calls, who cares about thread priority inversion anyway?

    Er, yes. If you look at WASAPI (or DirectSound before that) it's very much an asynchronous design. I'm not sure where the idea that means you have to deal with multiple threads come from though, unless that's something C# is doing on top of the native APIs. Which would only add to the "don't use managed languages for low latency work" argument.

  • async and lock

    You do realise that all IO on Windows has always been Async, right? The synchronous versions have only ever been convenience wrappers.