Optimized Watch

[Solido]

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]

Oh interesting thought!

Could you share some pseudo code as an example?

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

[Solido]

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]

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]

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]

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]

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]

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

[Solido]

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]

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]

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]

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]

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]

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]

Done: 7b3946a#diff-63ce0e9e3075cb9804fd530981bb14c59a6dee8c73da4ea38f439d4c0eaee69fR70

[Solido]

I'm reading your commits on 6.0!

[rodydavis]

Decided on a new path.

Create new widget WatchBuilder that includes the child property on the builder and callback.

Update Watch to use WatchBuilder internally.

This will allow for an easy migration to v6 while in the future being able to deprecate one.

[Solido]

After migrating to the testing branch I expressed some code as

Watch((_,__) => ...)

As the second parameter is required even where child is not.
WatchBuilder will simplify that.

[rodydavis]

The latest removes that from Watch and only puts it in WatchBuilder!