Hi Hubert I've added support for v5.1.22 for the presence of a field called "throttle.refresh" triggering the same throttling process as for draft tiddlers. You can try it out here:
https://tiddlywiki.com/prerelease#RefreshThrottling Best wishes Jeremy. -- Jeremy Ruston [email protected] https://jermolene.com > On 11 Oct 2019, at 14:44, Hubert <[email protected]> wrote: > > > Just to add, sliders created using the <$range/> widget are now also smooth > as butter, as long as the tiddler being updated is an unsaved draft, eg: > > <$range tiddler="Draft of 'edit-range'" min=0 max=10 default=5 increment=0.5/> > > I've tested this on desktop and mobile. Even on desktop, removing the few > seemingly imperceptible miliseconds of choppiness made a huge difference. > This seems to make it clear that the benefits of delayed refresh go so much > farther and are not limited to smooth typing experience alone. > > Regards, > Hubert > >> On Friday, 11 October 2019 11:51:25 UTC+1, Hubert wrote: >> Hi Jeremy, >> >> Thank you for taking the time to respond, I appreciate it. >> >>> We could add an additional field that we check for along with the >>> “draft.of” field, such as “refresh.slow” as suggested in the thread above. >>> I don’t think that’s going to be particularly convenient in lots of >>> situations (e.g. ensuring that $:/temp/search gets that field). Another >>> possibility might be to use a special prefix e.g. $:/dampened/ or perhaps >>> $:/volatile/. >> >> I would be happy with either solution so long as such a non-draft tiddler is >> excluded from instant refreshes. Perhaps a tiddler having a field >> refresh.slow could be referenced in $:/temp/search in italics (similar to >> how shadow tiddlers are in bold)? >> >> May I ask whether this is something that could be considered for the next >> release? >> >>> I’m not sure what you mean here. Are you talking about the draft tiddler >>> notification at the bottom of the screen? >> >> Yes, that's exactly it. I've found it's defined in >> $:/core/ui/PageTemplate/drafts and have already overwritten it accordingly, >> removing only the single "Draft of..." tiddler I'm editing using >> <$edit-text/> widget in another tiddler. >> >>> I may have missed something in the thread earlier, but you can keep a >>> perpetual draft by not opening it directly, instead editing it via an >>> edit-text widget from another tiddler. >> >> This is exactly the approach I'm taking now, but I failed to express it as >> concisely. >> >> Best regards, >> Hubert >> >> >> >> >>> On Friday, 11 October 2019 11:25:09 UTC+1, Jeremy Ruston wrote: >>> Hi Hubert, >>> >>> Thank you for finding this thread from 2015: >>> >>> https://groups.google.com/d/topic/tiddlywiki/hlIvXE6jRys/discussion >>> >>> As you note, I think we are still in the same place: on lower powered >>> devices, it would be useful to be able to extend the refresh dampening >>> mechanism to selectively apply to tiddlers that are not drafts. >>> >>> The code that checks for tiddlers that should be included in refresh >>> dampening looks for the presence of the “draft.of” field: >>> >>> https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/render.js#L82-L88 >>> >>> We can change that logic, but we need to keep it simple because it will be >>> executed every time any tiddler is modified. So, for example, using a >>> filter would be ruled out. >>> >>> We could add an additional field that we check for along with the >>> “draft.of” field, such as “refresh.slow” as suggested in the thread above. >>> I don’t think that’s going to be particularly convenient in lots of >>> situations (e.g. ensuring that $:/temp/search gets that field). Another >>> possibility might be to use a special prefix e.g. $:/dampened/ or perhaps >>> $:/volatile/. >>> >>> You asked >>> >>>> Now I have to figure out how I can prevent this open text tiddler from >>>> being constantly referenced in a red notification rectangle >>> >>> I’m not sure what you mean here. Are you talking about the draft tiddler >>> notification at the bottom of the screen? >>> >>> >>> >>>> and to prevent TW from saving it, because once it exits editing mode the >>>> lag is reintroduced. >>> >>> I may have missed something in the thread earlier, but you can keep a >>> perpetual draft by not opening it directly, instead editing it via an >>> edit-text widget from another tiddler. >>> >>> Best wishes >>> >>> Jeremy >>> >>> >>> >>>> >>>> Regards, >>>> Hubert >>>> >>>> >>>> >>>>> On Friday, 11 October 2019 09:09:34 UTC+1, Hubert wrote: >>>>> Hi Mark, >>>>> >>>>>> My TW now has 63k entries, and, in a meeting the other day,I was able to >>>>>> look up entries about as fast as people asked. >>>>> >>>>> That's impressive. Did you use a search bar or your own <edit-text/> >>>>> widget? I'm particularly interested if it was the latter. >>>>> >>>>>> But that was using a Kindle Fire, which might have a stronger processor >>>>>> than a motorola phone. >>>>>> >>>>>> I don't believe you've mentioned what browser you're using. My tests >>>>>> were on an old version of FF that I'm not upgrading because it >>>>>> can still use TiddlyFox. >>>>>> >>>>>> It might be worth experimenting with different browsers. I believe >>>>>> browser makers have wide latitude in how they implement JS internals. >>>>> >>>>> I'm now at a Windows PC with i7 processor, 8 gigs of RAM and running >>>>> latest FF. The lag is still there, albeit of course not that annoying as >>>>> on mobile. Same issue on Chrome. >>>>> >>>>> >>>>>> On Thursday, 10 October 2019 16:29:56 UTC+1, Mark S. wrote: >>>>>> In my case, I kept the tags but removed all usage of the tag filter >>>>>> operator. My TW now has 63k entries, and, in a meeting the other day, >>>>>> I was able to look up entries about as fast as people asked. But that >>>>>> was using a Kindle Fire, which might have a stronger processor >>>>>> than a motorola phone. >>>>>> >>>>>> I don't believe you've mentioned what browser you're using. My tests >>>>>> were on an old version of FF that I'm not upgrading because it >>>>>> can still use TiddlyFox. >>>>>> >>>>>> It might be worth experimenting with different browsers. I believe >>>>>> browser makers have wide latitude in how they implement JS internals. >>>>>> >>>>>> Good luck! >>>>>> >>>>>> >>>>>>> On Thursday, October 10, 2019 at 8:00:47 AM UTC-7, Hubert wrote: >>>>>>> Sounds counter-intuitive, but I've just checked it nevertheless. >>>>>>> >>>>>>> Nope, 400 is much worse in my case. >>>>>>> >>>>>>> The circumstantial evidence I have so far is pointing to tags... >>>>>>> >>>>>>>> On Thursday, 10 October 2019 15:49:30 UTC+1, Mark S. wrote: >>>>>>>> I you know, I think experienced this before, and commented. Try >>>>>>>> resetting the timeout back to 400 and reloading. >>>>>>>> >>>>>>>> After setting the TO to 60000, it feels slower when typing into the >>>>>>>> input box. >>>>>>>> >>>>>>>>> On Thursday, October 10, 2019 at 5:53:07 AM UTC-7, Hubert wrote: >>>>>>>>> Hi Mark, >>>>>>>>> >>>>>>>>>> Just testing now, and setting it to 60000 doesn't seem to impact the >>>>>>>>>> speed with regular editing nor inside a form box. >>>>>>>>> >>>>>>>>> Have you reloaded the wiki after setting it to 60000? It might not >>>>>>>>> take effect until reloaded. >>>>>>>>> >>>>>>>>>> Is there anything special about your TW file? Have you tested on an >>>>>>>>>> empty ? >>>>>>>>> >>>>>>>>> No and yes, respectively. >>>>>>>>> >>>>>>>>> The lag on mobile may be more or less noticeable, which could even >>>>>>>>> depend on the size of the wiki and/or on the number of tiddlers >>>>>>>>> currently open. I lack the knowledge to draw conclusions but I do >>>>>>>>> suspect it has to do with the refresh mechanism. >>>>>>>>> >>>>>>>>> BTW. my wiki is just slightly over 5 megs. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Hubert >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Wednesday, 9 October 2019 21:15:04 UTC+1, Mark S. wrote: >>>>>>>>>> I've mentioned typing speeds in the past. I never found that the >>>>>>>>>> draft speed setting really changed anything one >>>>>>>>>> way or the other. Maybe it makes a difference on Mac but not on >>>>>>>>>> Android. >>>>>>>>>> >>>>>>>>>> Just testing now, and setting it to 60000 doesn't seem to impact the >>>>>>>>>> speed with regular editing nor inside a form box. >>>>>>>>>> >>>>>>>>>> Is there anything special about your TW file? Have you tested on an >>>>>>>>>> empty ? >>>>>>>>>> >>>>>>>>>> Good luck! >>>>>>>>>> >>>>>>>>>>> On Wednesday, October 9, 2019 at 12:49:43 PM UTC-7, Hubert wrote: >>>>>>>>>>> Hi Mark, >>>>>>>>>>> >>>>>>>>>>>> What vintage is your phone? >>>>>>>>>>> >>>>>>>>>>> It's a fairly recent midrange Motorola. >>>>>>>>>>> >>>>>>>>>>>> What version of TW are you using? There are size/speed >>>>>>>>>>>> improvements in 5.1.20. >>>>>>>>>>> >>>>>>>>>>> I'm using the latest stable TW version (5.1.21). >>>>>>>>>>> >>>>>>>>>>>> I tried your test on the full downloaded TiddlyWiki.com page on my >>>>>>>>>>>> 2012 era samsung phone. The speed of course was slow, but it was >>>>>>>>>>>> the same for the edit box as for editing the tiddler itself. >>>>>>>>>>> >>>>>>>>>>> Thanks for having a go with the test on mobile. Have you modified >>>>>>>>>>> the TypingTimeout value before testing? I'm having a "native" (no >>>>>>>>>>> lag) typing experience when editing a tiddler after setting the >>>>>>>>>>> value in $:/config/Drafts/TypingTimeout to 60000. By default, this >>>>>>>>>>> value is around 400 (ms), which results in a noticeable lag in my >>>>>>>>>>> case, so just wondering. >>>>>>>>>>> >>>>>>>>>>>> You probably know this already, but be sure to not have your >>>>>>>>>>>> "recent" tiddler opened in the sidebar. >>>>>>>>>>> >>>>>>>>>>> Yes, I do :). I have it disabled across the whole wiki. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Wednesday, 9 October 2019 19:55:31 UTC+1, Mark S. wrote: >>>>>>>>>>>> What vintage is your phone? >>>>>>>>>>>> >>>>>>>>>>>> What version of TW are you using? There are size/speed >>>>>>>>>>>> improvements in 5.1.20. >>>>>>>>>>>> >>>>>>>>>>>> I tried your test on the full downloaded TiddlyWiki.com page on my >>>>>>>>>>>> 2012 era samsung phone. The speed of course was slow, but it was >>>>>>>>>>>> the same >>>>>>>>>>>> for the edit box as for editing the tiddler itself. In either >>>>>>>>>>>> case, the upper limit to typing was my ability to use the tiny >>>>>>>>>>>> keyboard. >>>>>>>>>>>> >>>>>>>>>>>> You probably know this already, but be sure to not have your >>>>>>>>>>>> "recent" tiddler opened in the sidebar. >>>>>>>>>>>> >>>>>>>>>>>> Good luck! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Tuesday, October 8, 2019 at 7:47:00 AM UTC-7, Hubert wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Before I go into details, my $:/config/Drafts/TypingTimeout >>>>>>>>>>>>> tiddler has a value of 60000 (60 seconds), which fixed the lag >>>>>>>>>>>>> when entering text / typing in a tiddler in edit mode. >>>>>>>>>>>>> >>>>>>>>>>>>> However, I'm still experiencing lag when entering text using >>>>>>>>>>>>> <$edit-text/> widgets (of course, the tiddler being populated as >>>>>>>>>>>>> I type is separate to the one that has the edit-text widget). >>>>>>>>>>>>> >>>>>>>>>>>>> This lag is negligible on my Chromebook or Windows PC (I have no >>>>>>>>>>>>> means of measuring it but even if it's 5ms then it's not much to >>>>>>>>>>>>> worry about) but it is very noticeable on Android (using Chrome >>>>>>>>>>>>> as an example). It gets better if I close all tiddlers except the >>>>>>>>>>>>> one that has the <$edit-text/> widget and I assume that the lag >>>>>>>>>>>>> has to do with TiddlyWiki re-rendering all the open tiddlers as I >>>>>>>>>>>>> type (though I'm not sure if that's the case). >>>>>>>>>>>>> >>>>>>>>>>>>> What exactly is introducing the lag when using <$edit-text/> >>>>>>>>>>>>> widgets? Is it realtime rendering? If so, could the scope of >>>>>>>>>>>>> $:/config/Drafts/TypingTimeout be extended to also include >>>>>>>>>>>>> <$edit-text/> widgets, so that the lag is fixed at the expense of >>>>>>>>>>>>> instantaneous rendering? Is there any other mechanism that is at >>>>>>>>>>>>> fault here? I do not believe that we should require a multicore >>>>>>>>>>>>> workstation to have a smooth typing experience. >>>>>>>>>>>>> >>>>>>>>>>>>> Typing into a tiddler in edit mode and entering text in a >>>>>>>>>>>>> password prompt both work with absolutely no lag on mobile (this >>>>>>>>>>>>> is the 'native' typing feel), but these are the only two examples. >>>>>>>>>>>>> >>>>>>>>>>>>> The <$range/> widget seems to suffer from the same lag >>>>>>>>>>>>> occasionally (it's not super smooth) but I'm not sure if it's >>>>>>>>>>>>> affected by the same root cause. >>>>>>>>>>>>> >>>>>>>>>>>>> Finally, apologies for awkward phrasing; English is not my first >>>>>>>>>>>>> language. >>>>>>>>>>>>> >>>>>>>>>>>>> Many thanks, >>>>>>>>>>>>> Hubert >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "TiddlyWiki" 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/tiddlywiki/fe01d5db-9694-480a-bb2a-bd0625a0812e%40googlegroups.com. >>> > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" 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/tiddlywiki/2c7ba11e-c57e-4189-9467-36cb1ae1213f%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" 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/tiddlywiki/99D16B26-CDFE-48F9-9791-07F6BFC403A2%40gmail.com.
