swiftshader VS engine

Is it really true that those bugs aren't getting fixed? There's a commit from July 18th to SwiftShader that seems to be addressing exactly the bug described in the blog post:

https://github.com/google/swiftshader/commit/4e401427f8dd799...

If your GPU does not support Vulkan you can still do some experimenting with a CPU renderer. I've used swiftshader a lot, it's a bit of a pain to compile, but once you manage to do so you can compile and run Vulkan code almost the same as if you had a compatible GPU. The performance of course is not great, but it's better than nothing.

swiftshader by Google (link):

You also don't get extensive support for various hardware for free – good luck running a Vulkan GUI on a pre-GCN AMD card or a sufficiently old NVIDIA one without a compatibility layer of sorts, which would require bothering with Vulkan Portability (i.e. missing certain Vulkan features due to it being implemented via an older API). The only alternative to that is SwiftShader (which would throw your extremely fast GUI aspirations right outta the window).

That's like saying no one needs a GPU anymore because Swiftshader exists.

Btw, if anyone's interested, here's the link to that branch: https://github.com/google/swiftshader/tree/legacy-d3d9

Yeah, there's still a fallback option through the use of Swiftshader if GPU accelerated vulkan isn't an option. If you use Vulkan for GUI, then it'll be fine to use Swiftshader, but if you're trying to play a game on Swiftshader, it'll likely struggle and probably fail.

The fix is https://github.com/flutter/engine/pull/25205 to use soft renderer SwiftShader instead of DXD9 on low-end PCs

Google’s version is SwiftShader

https://github.com/flutter/engine/blob/main/impeller/docs/fa...

Impeller is the Skia replacement and is in full c++ that supports all platform.

It will be great if Go team can work with them(both are in Google) and make Impeller a render engine for Go.

With this no more bloated electron.js and no more Java/Swing or Qt, what a dream for the day.

Likely it's https://github.com/flutter/engine/pull/41168 that fixed it, which got cherry picked into that commit.

Depends on what you want to do. The best documentation for writing the code where the engine should run in is in this header file.

Performance on large-screen and also high-refresh rate iPads was definitely a blind spot during the preview. We've done a ton of work to plug that gap since the preview though. Framebuffer fetch for advanced blends, improvement to blur performance, and using half-precision in performance critical shaders are just some of the improvements driven by these findings.

Yes. We use ATK for accessibility. FlAccessibleNode is where SemanticsNode and friends are exposed as ATK objects.

The hardware accelerated 3D that was demoed was using Impeller Scene. Considering they were loading glb files I really hope the Flutter API has a GLES interface. It's currently marked "Experimental" and the demo they showed unfortunately doesn't have source in the same place as the other demos presented.

For example for the last point, embed Flutter in HTML pages, an important PR is recently merged: https://github.com/flutter/engine/pull/37738