Fiber of filter

[linonetwo]

Filter steps could have been executed separatly, separated by requestIdleCallback, so huge wiki's filter calculation won't hurt mouse scrolling and typing experience.

Update: or use
https://developer.chrome.com/blog/new-in-chrome-129#yield

This is basically same as async widget rendering, because list widget will need to wait for filter calc complete.

Performance!

[Jermolene]

Hi @linonetwo the core refresh cycle needs to be entirely synchronous for performance. I don't see a way to get filter execution onto another thread because it would introduce asynchronous communication. Using worker threads for rendering works well, but only if one is rendering a bitmap; it does not work well when rendering DOM nodes. We might be able to use worker threads for things like precomputing indexes that are used in filter evaluation.

[linonetwo]

Don't need another thread, the fiber here is from "react fiber", it only means split filter steps' execution into multiple callbacks, and allow mouse events to be handled between them.
(there are articles about react fiber, basically just requestIdleCallback api calls)

Some users already complain about filter slowness to me, and I think sqlite won't fix this forever, because there will always be long running filters.

Can we add an async-list widget that renders nothing, and wait for async (or request IdleCallback) filter execution, then rerender it self with filter result? Just like it usually does on tiddler store changes, but now we have another change source, a filter execution completion store.

This allows mouse scroll or keyboard typing smoothly.

[Jermolene]

Thanks @linonetwo I wasn't familiar with React Fiber but found this article useful: https://sunnychopper.medium.com/what-is-react-fiber-and-how-it-helps-you-build-a-high-performing-react-applications-57bceb706ff3

In TW terms, this would be a matter of breaking the refresh process up to make it asynchronous, presumably by deferring the rendering of subtrees with a nextTick() handler. It would be a very deep rewrite of the mechanism, and would require a lot more state management and manual scheduling. For example, it would be possible for UI events to be triggered while a rendering is in progress (indeed, that is the point of the change). That would mean that the store could change during a rendering, which would then mean that we'd end up with an inconsistent render tree, with one subtree reflecting a different store state than it's ancestors. I guess we'd have to resolve that with some kind of locking mechanism.

My thinking is that the work needed in the refresh cycle is proportional to two significant variables:

1. the number of nodes that need visiting in the widget tree
2. the complexity of computation required by filter evaluation

The first of those numbers does have a natural upper bound: the widget tree complexity directly corresponds to the DOM tree complexity, and nobody wants an overly large DOM tree slowing down their browser.

The second variable doesn't have any natural upper bound: we can plausibly imagine arbitrarily complex filter computations in some applications. So I think the area for focus should be filter evaluation.

There is actually scope for making filter evaluation asynchronous: one could imagine executing a filter that returns a special empty value that marks that the results are not yet available. Then all we'd need to do is make sure that a refresh cycle occurs after the filter results are available. (I think it would actually be the construction of indexes that we could defer asynchronously, rather than the evaluation.

[linonetwo]

@Jermolene So only filter related widgets will need to rewrite, we don't need to touch the whole widget rendering process this time, nor need to run filter in another thread, like in #6550 (comment) . And we can only add this in a new async list widget, don't need to make other widgets async. I find DOM rendering is usually very fast, other widgets don't need to be async at all, and only filters on sidebar slow the huge wiki down.

(I think it would actually be the construction of indexes that we could defer asynchronously, rather than the evaluation.

Even with indexer, some of my filter will still be slow, like sameday filter, it will access tiddler store (this is also an index) thousands of times, and calculate up to 1S. So always need to deal with slow evaluation.

UI events to be triggered while a rendering is in progress (indeed, that is the point of the change). That would mean that the store could change during a rendering

If we are going to make an async version of list widget, it could have an loading indicator, means it has staled content, or filter evaluation is debounced. And user can click on loading indicator to force a sync filter evaluation.

If developers like this, then other widgets that accepts filter expression could also adapt this async filter usage.

one could imagine executing a filter that returns a special empty value that marks that the results are not yet available.

This will be a good chance to add first usage of Promise into TW.

If promise is not useable in current TW core, maybe we can use Observable style, no browser API or library needed, simply add a new filter related method, that returns an { subscribe, error, complete } object, but only error and complete are needed.

Async list widget refresh its subwidget tree when filter execution complete.

Old logics that relys on return value of refresh should still use old list widget for several years

if($tw.styleWidgetNode.refresh(changes,$tw.styleContainer,null)) {
	var newStyles = $tw.styleContainer.textContent;

and async widgets only used in UI that only human will read, where no JS will read things from elements. And provide an async fiber filter tiddlers method for plugin developers to use.

[Jermolene]

Hi @linonetwo I think the two proposals are essentially equivalent: I was coming from the perspective that there would be a new way to evaluate filters that would return immediately with an interim result that is marked as requiring re-evaluation, and you were noting that perhaps only the list widget need be updated to be able to run filters in the new way.

I think there is a possibility of being able to implement this without requiring any changes to the list widget. The idea is that qualifying filters evaluated during a refresh cycle would be accumulated, with each incomplete filter evaluation also producing an estimate of the time until the correct results are available. Then at the end of the refresh cycle we'd be able to look at the accumulated timings and figure out the next timestamp at which to force another refresh which would pick up the correct results.