raphlinus VS WebViewFeedback

That's surprising, given the legendary sense of humor of the C++ community.

I have some ideas on how to do boolean ops, some of which is written up in a blog post issue, and for which I have some code locally. In particular, the parabola estimate seems much more efficient than the usual fat line approach. I also have a sketch of quadratic/quadratic intersection in kurbo#230.

I am. It is relevant to the topic, and I cite it in the (now two year old) outline for the blog post I intend to write on the topic[1].

[1]: https://github.com/raphlinus/raphlinus.github.io/issues/40

I rewrote that paragraph, as I realize it comes across too contentious. Thanks all for the feedback!

To do video properly requires integration with the platform compositor. This is a fiendishly difficult problem, and I know of no serious effort to solve it. I have an outline of a blog post on the topic, and hope to publish it before too long.

I am working on this problem too, and have an issue on my blog with an outline of the writeup. Stay tuned!

> PS, is your monoid work online, is it this https://arxiv.org/abs/2205.11659 ? I'm interested in monoids on GPUs.

Yes, the draft is on arXiv, and I have a blog post in the pipeline[1] explaining it to a more general audience.

And thanks for the other advice, I'll consider it!

[1] https://github.com/raphlinus/raphlinus.github.io/issues/66

The new xilem async architecture is designed to integrate much more finely with async. I have an outline of a blog post in the queue but am juggling a lot of things right now. Expect to see some updates, but not super soon.

This is a hard problem and one of the hardest parts is figuring out scope. I have an upcoming blog post which will touch on some of the issues. In any case I'd love to see some progress on larger ecosystem collaboration.

The short answer is no, but the long answer is that this is a very complex tradeoff space. Going forward, we may see more of these types of tasks moving to GPU, but for the moment it is generally not a good choice.

The GPU is incredible at raw throughput, and this particular problem can actually implemented fairly straightforwardly (it's a stream compaction, which in turn can be expressed in terms of prefix sum). However, where the GPU absolutely falls down is when you want to interleave CPU and GPU computations. To give round numbers, the roundtrip latency is on the order of 100µs, and even aside from that, the memcpy back and forth between host and device memory might actually be slower than just solving the problem on the CPU. So you only win when the strings are very large, again using round numbers about a megabyte.

Things change if you are able to pipeline a lot of useful computation on the GPU. This is an area of active research (including my own). Aaron Hsu has been doing groundbreaking work implementing an entire compiler on the GPU, and there's more recent work[1], implemented in Futhark, that suggests that that this approach is promising.

I have a paper in the pipeline that includes an extraordinarily high performance (~12G elements/s) GPU implementation of the parentheses matching problem, which is the heart of parsing. If anyone would like to review a draft and provide comments, please add a comment to the GitHub issue[2] I'm using to track this. It's due very soon and I'm on a tight timeline to get all the measurements done, so actionable suggestions on how to improve the text would be most welcome.

[1]: https://theses.liacs.nl/pdf/2020-2021-VoetterRobin.pdf

[2]: https://github.com/raphlinus/raphlinus.github.io/issues/66#i...

You say that being web centric precludes usage on conventional gaming platforms. What about all the games that are PC only anyways? They could use Tauri or whatnot & have incredibly easy time porting to native.

Games such as Battlefield have already used web technology to power much of the game chrome. Taking this a step further doesn't seem like a real constraint. Microsoft themselves are working to extend fast performance webviews to Xbox uwp's. https://github.com/MicrosoftEdge/WebView2Feedback/issues/215...

You're also not acknowledging the upside. Plenty of games would love to have an easy-to-make runs-anywhere multi-parryty game. Letting people log in from work or their phone could be a huge advantage to reaching markets. The market of people with access to web browsers is much bigger than the market of console owners!

You're also constraining your thinking to a narrow band in other ways, again ignoring plenty of great potential. Unreal has had huge success gaining entry into all kinds of unexpected spaces; cinema, architecture, events. Engines have a much wider market than just games, and having engines available on a much broader set of modalities than conventional game engines can unlock new use cases. No one's going to build a navigation tool requiring everyone to have a Steam Deck, but if all it takes is a phone then maybe that becomes interesting.

This also seems like an amazing starter kit for education and hobby coders. Wouldn't it be amazing to be able to be a year or two into learning development, and be able to create your own virtual world? That anyone can easily join & access from any device? That potential makes me thrilled.

Maybe this innovation isn't for you & you want to stick to conventional modalities. Fine, great! Don't use this. I for one see a lot of potential & reason for excitement. I think it has plenty of revenue potential, and vast amounts of cool potential.

Drag and drop is still broken in WebView2, so all blazor Maui drag and drop is broken. This is still not being fixed by MS https://github.com/MicrosoftEdge/WebView2Feedback/issues/2805

Add Ons or Extensions with WebView2 (WebView2Feedback#98)

FIXED! RPG-254 Unbeknownst to me, Microsoft broke the toolbar on the WebView2 component that Sojour uses for displaying PDFs. The toolbar is now visible again and I have also fixed an odd threading issue, where once upon a time, opening a character sheet used to make that character sheet's window unresponsive for the first click. It's now responsive from the get-go.

Comment on the page point to a few GitHub issues for macOS and Linux support.

Linux: https://github.com/MicrosoftEdge/WebView2Feedback/issues/645...

> Hey all - We don't currently have a timeline for when we would begin this work. Unfortunately it's very unlikely to be soon.

macOS: https://github.com/MicrosoftEdge/WebView2Feedback/issues/131...

> No updates since @ningccn's comment above. We are continuing to make progress on Mac and haven't begun Linux planning yet.

"Microsoft Teams is getting big performance improvements".... but only for Windows!

Maybe some day we can have WebView2 in Linux[1] and others.

[1] https://github.com/MicrosoftEdge/WebView2Feedback/issues/645

Got some traction over on GitHub, please post your comments there! Microsoft has acknowledged this issue and is tracking: https://github.com/MicrosoftEdge/WebView2Feedback/issues/3136

Yep, and edge webview2 uses edge for the most part. Yet there's something specific to the edge webview2 runtime that makes it hard to port even if edge itself is already available on mac/linux. I think it's because it uses some windows specific APIs to expose functionalities that aren't available to regular webviews.

They were planning on maybe releasing the linux port around the end of 2021, as they were prioritizing the mac port first.

But I don’t think even the mac port has been released yet... So it kind of makes sense for the Teams team (ha!) to just not bother with a linux release if the runtime they are developing on isn't even on the release roadmap yet. Though I guess that makes the switch from electron even more confusing.

https://github.com/MicrosoftEdge/WebView2Feedback/issues/645