fzyzcjy

Thank you!

You are welcome and looking forward to it!

Thank you!

Thank you!

Yes, if someone needs to write UI using native Android/iOS code, Crux would be suitable. On the other hand, personally speaking, I prefer to write all code 1 time, but Crux seems to require to write the UI code 3 times for Android+iOS+Web.

Thanks for the information, and I replied bubblebeard above about Tauri.

Thank you! I heard some people saying that, for apps using JavaScript, Tauri is replacing Electron and is popular nowadays, since Electron is very widely used. It seems Tauri cannot let Rust communicate with JavaScript very seamlessly yet, e.g. https://tauri.app/v1/guides/features/command/ seems to have mainly basic features. oneshtein mentioned below that Tauri does not support mobile as first class citizen yet as well. Looking forward to seeing Tauri's bridge to improve and supporting mobile better in the future!

The first image at the bottom of that post may be related to your question: https://www.reddit.com/r/rust/comments/191b2to/rinf_copies_a... Btw, why is your name green?

For app size, it depends on your specific scenario, because e.g. Flutter automatically removes library code that is not used. I remembered (but the memory is blur) simple app has something like ~5MB. Btw remember to split .so file per abi. For UI performance, I personally find it quite good, and Flutter(Dart) is compiled to assembly code via AOT (instead of e.g. JIT or interpreted), which theoretically speaking is also fast. For both, I would suggest to make a demo for your specific case to have more accurate results. Also I guess ask/discuss on the Flutter community may help.

Thanks! Shortly speaking, the Rust code is parsed (e.g. "here is a function and there is a struct"), and then some Rust and Flutter code are generated. As for comparison, some pros and cons are discussed in the blog.

You are welcome, and I am happy to see it helps! When I initially develop flutter_rust_bridge, my personal usage scenario is quite similar to yours: using Rust for some high performance algorithms.

You are welcome, and happy to hear it works for you!

I see. So you want to have some hard things? Make a PR then - the underlying impl is quite hard ;)

Thanks.

I will make an ELI5 explanation later when having time - you know, it is much harder to explain something ELI5 instead of discussing the tech details. There is a full long chapter about non-ELI5 explanation though.

> If this fixes Flutter, why not put these changes in the main Flutter source

I have been making a ton of PRs to Flutter :) I also discussed w/ Hixie on public discord channels about being into Flutter, but later we concluded that it is much easier to be a 3rd party package.

> I'm a bit confused, if this is a 60 fps for free with some renaming, why is it that easy ... Something feels fishy here.

Sorry what is "with some renaming"? Not get it, it is not renaming, but literally really ~60FPS.

You can see benchmark chapter for the details, or download and compile the app and run on your own phone and look at source etc. If you find it not ~60FPS, feel free to create an issue with your profiling data so I can see what bug it is.

> This is cool, dont get me wrong, but I just dont see how its "this" easy to fix jank/60 fps.

Hey this is not "this" easy - I have spent a whole full month without weekends and with a ton of failures! And please see the "design" chapter - a ton of work indeed. So it is never "easy".

Hi friends, after a month working on it full-time, I managed to make arbitrary Flutter apps ~60FPS smooth regardless of how janky it originally was due to build/layout.

For demonstration, there is a 3-second video in GitHub README. You can also find more details in the "Benchmark" chapter, where I experimented it and see it runs at (roughly) full FPS, feel smooth, has zero uncomfortable janks, with negligible overhead.

There are two ways to use it: For common scenarios, just add six letters ("smooth"), such as using SmoothListView instead of ListView. For complex cases where you want customization, use SmoothBuilder and put things that you need to be smooth inside the builder (just like how you use Builder everyday, but smooth).

As for how it is implemented, I have written down a full chapter ("Design" chapter) in the documentation.

Story time: Indeed I have failed a ton of times before finding out this solution. The "literature review" section summarizes them so I do not repeat here. It is another ton of failures before the theory becomes truth. At around half a month I was almost going to give up, because it stuck at less than 40-50FPS instead of the perfect ~60FPS, and my theory seems does not consider the scenario after a janky frame properly at all. But later I managed to patch my theory to fix the problem (seen in "post draw frame" section of doc). After that I fixed many edge cases one by one, where each problem causes (for example) 1FPS drop, then finally reached near 60FPS.

I also thought about this when reading the title. Would be great to see a comparison between the new tool and postwoman

This looks interesting! But it keeps loading forever saying "Your server is being created" (hit VM limit again?)