5 ms·

Microsoft most major chromium impact is to move input handling off the main thread which has been empirically a massive success on Edge. This would allow chrom

Microsoft most major chromium impact is to move input handling off the main thread which has been empirically a massive success on Edge. This would allow chrome to have lower input lag than native GUIs if it's not already the case. They are also working on many cool things, openXR support for example. They are improving chrome devtools (and their integration within vscode) They are doing many performance related fixes. And they are massively modernizing windows apis used by Chrome. E.g better performance for sensors through new windows 10 API. And the smart use of a Kalman filter for sensors. They are also helping chromium to support windows ARM 64 bit A real time view of what they are doing: https://chromium-review.googlesource.com/q/author:*.microsoft.com+AND+status:merged https://chromium-review.googlesource.com/q/author:*.microsof...

blackflame7000 7y ago
If only Microsoft would make it so easy to move input handling off the main thread when writing programs for Windows. MFC was the bane of my existence starting out.
- asveikau 7y ago
  Be careful what you wish for. I have witnessed people in contexts like these, thinking that threads are magic performance enhancing pixie dust, and unable to reason through the subsequent bugs.
  - ComputerGuru 7y ago
    async/await helps with that, but like with any other abstraction, if you use it without understanding how it works and what it actually does, it’s bound to come back and bite you at some point.
    - pragmatic 7y ago
      How exactly? The use case for perf improvement with async/await is for IO based issues, eg instead of burning a thread waiting for IO to complete, use IO completiion ports (on winders) blah blah. If your work is CPU bound you can't async/await it away magically. Maybe I'm misunderstanding you?
      - blackflame7000 7y ago
        Yea I’m also confused. You’re main thread should be able to run completely asynchronously from worker threads. With async, you are constantly hitting a memory barrier while the worker thread completes the promise and then the main thread draws the result. Ideally, the worker thread should be able to natively queue its task for non-blocking repaints. Side note, this is why I’m a huge fan of Qt. They really did a fantastic job on building that framework for c++ to make it more safe
      - ComputerGuru 7y ago
        I was specifically referring to input handling off the main thread, from GP’s original complaint. IO only.
      - manigandham 7y ago
        async/await is about non-blocking, not IO specifically. You can use async to not block the current thread while IO completes, or use it not block while while some CPU work completes (in this case on another thread while the UI is unblocked). It's similar to using an event loop architecture for all UI actions.
- pjmlp 7y ago
  That had already done that back in Windows 8 introduction. You just need to code with UWP and async/await.
pdonis 7y ago
> Microsoft most major chromium impact is to move input handling off the main thread which has been empirically a massive success on Edge. I'm confused by these statements (not just yours but in the article as well) about how Edge performs so well; I have not seen anything like that on the Windows 10 systems I am forced to use (for work). On those systems Edge takes forever to load, forever to open a new tab, and will randomly make the mouse cursor disappear when it's doing something it considers more important than responding to my input.
- awinder 7y ago
  Edge with chromium is still on the insiders channel so if it’s from work systems you probably have only been on their engine (is/was it trident?)
  - cptskippy 7y ago
    Trident was IE's rendering engine.
  - ComputerGuru 7y ago
    EdgeHtml + Chakra. Trident was the old IE one.
- The_rationalist 7y ago
  Well your experience is a data point, maybe it was not bug free. Anyway I was referring to this https://www.google.fr/amp/s/blogs.windows.com/msedgedev/2017/06/01/input-responsiveness-event-loop-microsoft-edge/amp/ https://www.google.fr/amp/s/blogs.windows.com/msedgedev/2017...
- cptskippy 7y ago
  Neither the Chromium or nonChromium based versions of Edge behave like that. It seems like your work machine has something impeding performance.
  - pdonis 7y ago
    > It seems like your work machine has something impeding performance. I thought it might be that, but it so happens we had to get a Windows 10 machine for home use for a particular purpose, and Edge on it is also slow (though perhaps not quite as slow as my work machine). Both are Dell laptops, so it's possible that Dell puts some extra OEM stuff in that hurts performance.
magicalist 7y ago
> Microsoft most major chromium impact is to move input handling off the main thread which has been empirically a massive success on Edge. Do you mean this would be their most major impact? The link you posted below is for Edge 15 and not for chromium. But in chromium the scheduler should already be handling input off the main thread when possible. Otherwise agreed with the point that this article is weirdly focused on a single somewhat underwhelming change when there have already been a bunch of changes.
toast0 7y ago
> Microsoft most major chromium impact is to move input handling off the main thread which has been empirically a massive success on Edge. Is that why sometimes Edge queues up UI actions while pages are loading? Having stop and back and whatnot wait to be processed until whatever stuck thing gets unstuck isn't exactly what I had in mind.

blackflame7000 7y ago

If only Microsoft would make it so easy to move input handling off the main thread when writing programs for Windows. MFC was the bane of my existence starting out.

asveikau 7y ago
Be careful what you wish for. I have witnessed people in contexts like these, thinking that threads are magic performance enhancing pixie dust, and unable to reason through the subsequent bugs.
- ComputerGuru 7y ago
  async/await helps with that, but like with any other abstraction, if you use it without understanding how it works and what it actually does, it’s bound to come back and bite you at some point.
  - pragmatic 7y ago
    How exactly? The use case for perf improvement with async/await is for IO based issues, eg instead of burning a thread waiting for IO to complete, use IO completiion ports (on winders) blah blah. If your work is CPU bound you can't async/await it away magically. Maybe I'm misunderstanding you?
    - blackflame7000 7y ago
      Yea I’m also confused. You’re main thread should be able to run completely asynchronously from worker threads. With async, you are constantly hitting a memory barrier while the worker thread completes the promise and then the main thread draws the result. Ideally, the worker thread should be able to natively queue its task for non-blocking repaints. Side note, this is why I’m a huge fan of Qt. They really did a fantastic job on building that framework for c++ to make it more safe
    - ComputerGuru 7y ago
      I was specifically referring to input handling off the main thread, from GP’s original complaint. IO only.
    - manigandham 7y ago
      async/await is about non-blocking, not IO specifically. You can use async to not block the current thread while IO completes, or use it not block while while some CPU work completes (in this case on another thread while the UI is unblocked). It's similar to using an event loop architecture for all UI actions.
pjmlp 7y ago
That had already done that back in Windows 8 introduction. You just need to code with UWP and async/await.

pdonis 7y ago

> Microsoft most major chromium impact is to move input handling off the main thread which has been empirically a massive success on Edge. I'm confused by these statements (not just yours but in the article as well) about how Edge performs so well; I have not seen anything like that on the Windows 10 systems I am forced to use (for work). On those systems Edge takes forever to load, forever to open a new tab, and will randomly make the mouse cursor disappear when it's doing something it considers more important than responding to my input.

awinder 7y ago
Edge with chromium is still on the insiders channel so if it’s from work systems you probably have only been on their engine (is/was it trident?)
- cptskippy 7y ago
  Trident was IE's rendering engine.
- ComputerGuru 7y ago
  EdgeHtml + Chakra. Trident was the old IE one.
The_rationalist 7y ago
Well your experience is a data point, maybe it was not bug free. Anyway I was referring to this https://www.google.fr/amp/s/blogs.windows.com/msedgedev/2017/06/01/input-responsiveness-event-loop-microsoft-edge/amp/ https://www.google.fr/amp/s/blogs.windows.com/msedgedev/2017...
cptskippy 7y ago
Neither the Chromium or nonChromium based versions of Edge behave like that. It seems like your work machine has something impeding performance.
- pdonis 7y ago
  > It seems like your work machine has something impeding performance. I thought it might be that, but it so happens we had to get a Windows 10 machine for home use for a particular purpose, and Edge on it is also slow (though perhaps not quite as slow as my work machine). Both are Dell laptops, so it's possible that Dell puts some extra OEM stuff in that hurts performance.

magicalist 7y ago

> Microsoft most major chromium impact is to move input handling off the main thread which has been empirically a massive success on Edge. Do you mean this would be their most major impact? The link you posted below is for Edge 15 and not for chromium. But in chromium the scheduler should already be handling input off the main thread when possible. Otherwise agreed with the point that this article is weirdly focused on a single somewhat underwhelming change when there have already been a bunch of changes.

toast0 7y ago

> Microsoft most major chromium impact is to move input handling off the main thread which has been empirically a massive success on Edge. Is that why sometimes Edge queues up UI actions while pages are loading? Having stop and back and whatnot wait to be processed until whatever stuck thing gets unstuck isn't exactly what I had in mind.