engine VS blurhash

This is all because I don’t trust the dispose() function. I need to call the _cancelTimer()routine and stop the Timer. However, I usually don’t use the dispose() method to do this. It’s unreliable to run any mission-critical operations and or release any substantial resources. You see, it’s to the Virtual Machine’s (VM) (i.e. Flutter Engine) discretion to call a State object’s dispose() function as part of its garbage collection responsibilities. You will have no idea when that happens. Due to some memory constraints, it’s not called at all — at least not when you may want to. The deactivate() method is more reliable and is more consistent. I use the deactivate() method, but that means I also use the activate() method — in case the Widget is moved around the Widget tree — the Timer must be initialized in our case. That’s just the way it is.

Impeller - Flutter’s rendering library that replaces Skia on iOS and Android - is working on a C API: https://github.com/flutter/engine/blob/main/impeller/toolkit...

https://github.com/flutter/engine/graphs/contributors

We are aware that these priorities might change in the future. There have been sanity checks to ensure that the Impeller API can be ported to WASM and also that Impeller shaders can be compiled to WGSL for eventual WebGPU support.

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

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.

A very compact representation of a placeholder for an image. Store it inline with your data and show it while the real image is loading for a smoother loading experience. It's similar to BlurHash but with the following advantages:

Now that you have the generated blurhash string, all that’s left is to display it on your frontend. There are plenty of libraries that can help you do just that—links and documentation can be found in the official BlurHash repository. Let’s keep pushing the boundaries of UX and make our interfaces as pleasant and responsive as possible!

AvifHash leverages the power of AVIF to create image placeholders that are both compact and efficient.

This Proof of Concept shows promising results: at 28 characters, AvifHash outperforms BlurHash https://blurha.sh/ (using 4x3 components) in quality and detail retention. At a similar quality, BlurHash needs 54 (5x5) to 76 characters (6x6 components).

Given that AVIF decoding is done by the web engine, AvifHash is very small: the entire demo page (including parsing and re-hydration code) is only 2.3 kB gzipped.

BlurHash website: blurha.sh

Blogspam, including just taking over the source images.

Original: https://blurha.sh/ and https://blog.wolt.com/hq/2019/07/01/how-we-came-to-create-a-... (2019)

While it's similar to BlurHash, the color performance is much better for the same filesize. Here's a a demonstration of this from the demo page (with ThumbHash in the middle and BlurHash on the right):

Package Link - https://blurha.sh

If you do go this way, you can use https://blurha.sh

No blurhash for images like Next or Gatsby