rodydavis / signals.dart

Reactive programming made simple for Dart and Flutter
http://dartsignals.dev
Apache License 2.0
475 stars 53 forks source link

Optimized Watch #318

Open Solido opened 2 months ago

Solido commented 2 months ago

It would be a nice addition to have Watch manage child widget to avoid full rebuild.

It's possible with current API but we have to build the child outside and pass it to builder by context.

This can be a costly error for beginner who are unaware of the process. The moment they start working with Asset like image the whole UI can start to blink.

Having a document Widget? child attribute would suffice to explain what's going on or and extended constructor around an existing child that would rebuild on signals update.

rodydavis commented 2 months ago

Oh interesting thought!

Could you share some pseudo code as an example?

The image widget is a good example use case for sure.

Solido commented 2 months ago

Just fall for it this morning. Nothing I can share cause code is not public but the concept is exactly the same than AnimationBuilder where I use expensive ops (think large asset and transform).

I've a dedicated widget that just received a Watch in the Tree and everything start blinking because each update force the reload of asset and transformation is then applied to the whole context.

Want I want is just passing the child that is cached into memory and apply transformation.

As an alternative I can rely on ForegroundPainter but our case with Watch is more ubiquitous and even more dangerous if relying on signal animation capacities.

I wish I can show you what I've done with Signals it's beyond anything else I've done before ^^

rodydavis commented 2 months ago

Oh i see! I can add an optional child property to the builder!

Sounds super amazing!

I am also working with painters and transforms with signals, but I usually use the painter + custom multi child delegate: https://rodydavis.github.io/flow_image_editor/

Solido commented 2 months ago

Yep I'm following your commits, I know it is one of your special objective :) I think I can share some of the last project with you. Let me move it forward enough.

Solido commented 2 months ago

Ah no I did not saw this one :D Really COOOL!

Are you aiming for a Blender Geometry Node tool?

You know I'm a big aficionado of coding my photos filter myself? Even doing some dedicated LUT.

rodydavis commented 2 months ago

Thanks! It will be a package that anyone can define custom nodes and the package will handle all the interaction state.

All possible because of signals!

rodydavis commented 2 months ago

The flow image editor app I want to open source and allow for contributions to custom nodes and filters!

Solido commented 2 months ago

Not the place to discuss it but if Dart is more than qualified to be the front it's not the same on applying efficient matrix ops. When you enter the field of photography, I doubt it can complete any ops on 16 bits Labs in a chain.

To my little hands down experience https://github.com/libvips/libvips is the way to go. So FFI as a front would be a nice path only if you want a web solution.

Just the 2 cents of a LUT creator ;)

rodydavis commented 2 months ago

Oh that's awesome! And yeah I was meaning more for the nodes for creating a pipeline that is not really realtime.

The flow image editor only runs each operation when each dependency changes using a computed so it would I guess run the LUT once and cache it.

But yeah we can chat more offline 😎

NabilaWorks commented 2 days ago

I looked into this briefly..

For high performance animations / widget caching, Flutter uses a different function signature for the builders in AnimatedBuilder, ListenableBuilder namely :

Widget Function(BuildContext, Widget?) builder

Whereas signals uses :

T Function(BuildContext context) builder

Adding an additional Widget? as part of the normal Watch builder will likely break everyone using signals and require them to migrate to the new signature?

I wonder what the smoothest way to add a child parameter would be in this scenario..

Adding an optional T Function(BuildContext, Widget?) builderWithChild to the Watch widget or maybe introducing a new constructor?

rodydavis commented 2 days ago

Since we are launching v6 I think it would be a perfect time to change the signature.

I do know it would be a breaking change for anyone using it but we might could offer a codemod?

The alternative would be to add a named constructor and it could be ignored for the others (my preference).

We could also add a new widget called WatchBuilder or something

Solido commented 2 days ago

Break the signature, it won't be much a burden to update the code plus it will align with Flutter. If possible limit the number of constructors/widgets/methods to keep the API surface accessible.

Others state-mngts felt for it and they're too complexe to learn or too specific while Signals may aim to be simple and accessible on first read.

rodydavis commented 2 days ago

Sounds good! Will break it for v6. I think it is the right call and especially as we make it easier to work with ValueNotifier and Streams

rodydavis commented 2 days ago

Done: https://github.com/rodydavis/signals.dart/commit/7b3946aa69bdcf7bcc18b9cf6e8b5a1894ca30a5#diff-63ce0e9e3075cb9804fd530981bb14c59a6dee8c73da4ea38f439d4c0eaee69fR70

Solido commented 2 days ago

I'm reading your commits on 6.0!