Mario

Perhaps dynaview is a partial or complete answer to this but its not really 
accessible to most users. Perhaps a helper method would democratise its 
use. Eg wrap wikitext output such that it only renders the visible.

I already have a snapshot plugin that saves the result of a complex 
tiddlers output, as html, and displays that rather than rendering the wiki 
text every time the tiddler is opened or a change causes it to be rendered 
again. I will share if asked. In this snapshot tool clicking it again 
renders the tiddler again and snapshots in agaiN, but in the mean time the 
user must wait. I wonder why we cant push it to the background?

If we could provide the above facility, a independant threadding  and 
dynaview the results i believe it could provide a perfomance improvement 
for larger processes and for report style tiddlers which in many way is a 
promise implied in the way tiddlywiki works. This would help reduce 
performance issues that arrise from tiddlywikis architecture when extended 
to larger datasets.

Further if rather than rerender a tiddler with a change detected we could 
simply flag that tiddler as abridged, then the user can chose to continue 
to view the snapshot or refresh the tiddler or a background process is 
triggered.

A lot of graphics bottle necks were overcome by rendering off screen before 
being switched into view.

Regards
Tones



On Tuesday, 8 September 2020 at 06:03:55 UTC+10 PMario wrote:

> On Monday, September 7, 2020 at 9:04:18 PM UTC+2, [email protected] wrote:
> ..
>
>> Instead, I'm wondering if shifting the rendering of many tiddlers that 
>> match a filter into the background might be a useful hack in this case, and 
>> I don't think it would be *too *hard to do.  There could be a 
>> <$lazy-list> widget that could run a filter, store its results, and then 
>> transcludes a temporary tiddler.  In the background, a timer would take a 
>> couple results from the filter at a time and render them to the temporary 
>> tiddler, building it up dynamically.  In my experience, it's the rendering 
>> that takes up much of the time when building large lists of tiddlers like 
>> this.
>>
>
> Hi Rob, 
>
> You are right. Filtering isn't the "time consuming" task. It's building 
> and drawing the DOM. Especially if you do a 
>
> list [all[]] ... In your case it will create 8700 links, where you can 
> only read may be 50 at the same time. 
>
> You should experiment with the tiddlywiki/dynaview plugin ... I did create 
> a version. see attachment 
>
> IMO it will be much more effective then optimizing filters and drawing 
> stuff that is nod visible. 
>
> -mario
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/73aef7de-bd43-466f-bca7-b1414ada8581n%40googlegroups.com.

Reply via email to