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
> 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.
> 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.
> 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.
The Chromium based edge has not been released outside of Insider/Beta previews currently so the GP’s experiences aren’t relevant to the current chromium based builds.
> 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.
I'm on a Lenovo X1 Thinkpad and Edge definitely doesn't feel slow to start here (it's instant), and while pages are maybe a bit slower to load than Firefox Quantum, I wouldn't call Edge slow. I can't compare against Chrome though - I don't use it because it chews through battery.
I think I have seen that disappearing mouse issue though, and mostly I use Edge when I double click on a PDF file and forget I don't have a PDF reader installed....
Not slow for me as well. It's my second browser beside FF and has the far better text to speech. Hard to compare performance, since my usage pattern differs widely between the two. But my biggest complaint would be tabs sometimes crash-and-reloading and some websites not rendering (bugs.chromium.org is an example).
Wonder how annoying the switch to chromium will be :/
FWIW I always thought of Edge as slow but just recently I picked up a Surface Go. It's not a fast computer... but somehow, Edge is pretty fast on this machine.
Every single version of Edge I have used has had unexplainable random pauses and jitter in GUI responsiveness. If they do some "clever" side-thread processing and queueing of inputs, I can imagine where this comes from. It was the number 1 thing preventing me from giving Edge more than a cursory try.
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.
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.
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.
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.
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
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.
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:*.microsof...