Typing lag in <$edit-text/> widget

[Hubert]

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

[TonyM]

Hubert,

The lag often occurs when you are editing text or fields in the same or another tiddler that is being rendered in front of your eyes.

If you can edit values in a tiddler that is not visible this can be eliminated. 

There are workarounds, and I have built these into a number of sophisticated solutions I have built (not yet published), but while I can hint at how I have done it, I can not possibly document this, because it is annoyingly complex and self referential (that being the problem here). Edit: I proved myself wrong, see later replies in this thread by me

• Place the edit text in a macro in another tiddler that references the current tiddler
• Use a View template to overlay the current tiddler with the edit text macros
• something else that is not quite so obvious.

I have on a number of occasions tried to communicate a need to remedy this by providing a mechanism to reduce the complexity of this practice. I almost always get negative technical responses rather than positive creative solutions. Since I have done it, I know it is possible and workable, that is, it is technically possible, but due to its complexity and my current knowledge, I am not yet ready to publish my solution (I have tried) let alone show how a better mechanism could be designed. It is technically feasible, it is one of tiddlywikis worst features, it needs a solution.

Regards

Tony

[Birthe C]

Hi Tony,

You seem to have a lot of exiting things going on. Need and curiosity is getting the best of me when reading about it. You know curiosity killed the cat...and (Do I need to say more...).

I understand that complexity and lack of time can make it difficult to publish the all shining and glamorous solution, but is it not possible in a wiki to show us some examples and list the needed tiddlers. That would, I am sure, give you some feedback and even suggestions to make it even better. Your choice of course.

All respect for your work,

Birthe

onsdag den 9. oktober 2019 kl. 00.29.40 UTC+2 skrev TonyM:

Hubert,

The lag often occurs when you are editing text or fields in the same or another tiddler that is being rendered in front of your eyes.

If you can edit values in a tiddler that is not visible this can be eliminated. 

There are workarounds, and I have built these into a number of sophisticated solutions I have built (not yet published), but while I can hint at how I have done it, I can not possibly document this, because it is annoyingly complex and self referential (that being the problem here).

[TonyM]

Birthe,

Seriously, I have attempted to a number of times, even create minimal test case. But have failed. It is easy to get caught in complex loops and twists where the slightest change breaks it. 

I will have another go.

Regards

Tony

[TonyM]

Here we Go, Example 1

In a tiddler called CodeTiddler place 

Description: <$edit-text field="description" size=80/>

In a tiddler called "Edit view" tagged $:/tags/ViewTemplate enter

{{||CodeTiddler}}

Click on the $:/tags/ViewTemplate tag pill and drag the "Edit view" to above $:/core/ui/ViewTemplate/body

Notes 

• This does not work on the CodeTiddler or Edit view themself but you can edit the current tiddlers description field on any other tiddler without lag or focus loss.
• Fields are created as soon as you enter something (nice fact)
• Note the use of "||" in the CodeTiddler! this means transclude here with the currentTiddler, otherwise you will edit yourself and it breaks.

Regards

Tony

[TonyM]

Example 2

In a tiddler called CodeTiddler place 

Caption: <$edit-text field="caption" size=80/>


In a tiddler called GlobalMacro tagged $:/tags/Macro place

\define edit-caption() {{||CodeTiddler}}

In any tiddler place

<<edit-caption>>

Notes 

• This does not work on the CodeTiddler itself but you can edit the current tiddlers caption field on any other tiddler containing the macro without lag or focus loss.

Regards

Tony

[TonyM]

Hubert,

If you use the online forum to access Google Groups you can actually edit your original post. One idea for collaboration is if you are happy with the result update your initial post with the answer you accepted, but leave the original intact.

Regards

Tony

On Wednesday, October 9, 2019 at 1:47:00 AM UTC+11, Hubert wrote:

[Birthe C]

Thank you Tony,

And now I recall. It was you who came up with the QuickDB I am using that one for a lot of stuff now. For years I have tried to get my partner and my best friend to use tiddlywiki. No big luck, I am afraid. QuickDB with a lot of other easy stuff got at least some interest - at least they are now keeping an eye on my Tiddlywiki. (There may be trickery and necessity into that effect also......;-) )

I am a much simpler user, but I really understand what you are saying, being cornered in a TW project. That happens all the time, because we get more ideas than we have time...and it is a never ending story getting even more into it. I think it is a question about how early on the route we get caught up LOL.

Birthe

[TonyM]

Birthe C

I had a habit of naming things quick in the past, but do not recall QuickDB

Yes, Tiddlywiki is a "divergent thinking muse".

Regards

Tony

[Birthe C]

Tony,

I recalled QuickDB because it is field editing in viewmode, and having an edit-field-list to enter the names that will be the entries in the db.

Very lovely when being in a hurry, saving the little details.

Birthe

[Birthe C]

Tony,

I found it: https://groups.google.com/d/msg/tiddlywiki/kLqyVrjcJ50/EyawWyGCEQAJ 

Birthe

[Hubert]

Hi Tony,

Thanks for taking the time to help.

I'm sorry that I didn't make it more clear in my original post (which, I admit, is a bit convoluted) -- I'm not attempting to type into the current tiddler using edit-text as this will of course introduce lag and loss of focus. This is a known issue with quite an easy workaround and this is not something that I'm facing.

Your solutions are clever and well thought out but, I hate to say this, they still lag on mobile for the simple fact that having separate tiddlers to "write/being written to" is not a solution, it is a prerequisite.

The culprit in lagging is in the widget refresh mechanism, as I have learned through searching this forum in-depth since I made this post. Again, this may not be much of a problem on desktops/laptops etc. but it does become a major usability problem on mobile.

To reference what my issue is, here's a post from about 2 years ago brought up by Evan Balster. If I see that correctly, no solution has been proposed since then.

I believe that the fix (again, mostly manifesting itself on mobile) would involve two things:

• using separate tiddlers: one containing the edit-text widget, another one being typed into (this one is obvious, though it's a frequent mistake made by TW noobs)
• the introduction of, perhaps, a parameter or a user-adjustable attribute to the edit-text widget that will affect the widget refresh mechanism, eg. <edit-text tiddler=test refresh=6000/>
  

Tony, again, thank you for your time and for your ideas and I'm sorry that I didn't make myself clearer in my original post.

Regards,

Hubert

[TonyM]

Hubert,

I stand to be corrected, and will test on mobile myself. Perhaps something I did not make clear I tend to allow edit and view of content through the view template such that there is nothing in the current tiddler that needs refreshing. In my examples of caption and description these are not displayed by rendering the current tiddler but by refreshing the view template, the same ui elements in which you are typing.

If as you suggest it must be a seperate tiddler and I assume undisplayed tiddler, then I potentialy have another solution up my sleeve. However I will examin your argument and mobile use to understand more, before proposing that other method. I only partialy understand the refresh argument but if you can concieve of even a long winded solution to this I think I can simplify it.

I love a seriouse challenge, especialy when it seems imposible.

regards
Tony

[Hubert]

Thank you Tony.

Perhaps something I did not make clear I tend to allow edit and view of content through the view template such that there is nothing in the current tiddler that needs refreshing. In my examples of caption and description these are not displayed by rendering the current tiddler but by refreshing the view template, the same ui elements in which you are typing.

That was perfectly clear Tony and I fully understand your approach. I use view templates myself in my own wiki, quite extensively, and your solution constitutes a form of "reverse transclusion". I use the more traditional approach in that, at the most basic level, I write in tiddler "One" that has the edit-text widget to update a tiddler "Two" (or any of its fields of indices, for that matter), where "Two" is out of view (closed, folded etc.) and where "Two" is not the current tiddler.

Both approaches are similar in that we don't type into the current tiddler. This is the quite obvious prerequisite. Once that's out of the way (the totally avoidable loss of focus, which I'm not talking about here), the refresh mechanism remains the sole issue and, I believe, the root of the problem I'm reporting. Again, the problem is barely perceptible on desktops/laptops but is an issue on mobile.

Please consider this: please create a new Tiddler titled "Typing" and paste this bare bones edit-text widget into its body (no need to create any additional tiddlers):

<$edit-text tiddler="test"/>

Now open the wiki on mobile, close or fold all tiddlers and navigate to the tiddler "Typing". Now, try typing anything. The lag is still there. No dependencies, no complex code. The lag persists. In my humble view, there is no fix other than an upgrade of the refresh mechanism itself, which is part of the core and something that Jeremy is overseeing.

Regards,

Hubert

[TonyM]

Hubert

Thanks for the example. I reproduced it in tiddloid. I see even back space lags.

Now I have something to hack.

Regards
Tony

[Mark S.]

Hah! You don't remember something you wrote? Welcome to my world! ;-)

[Mark S.]

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!

[Hubert]

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.

[Mark S.]

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!

[Hubert]

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

[Hubert]

Update: having read Mark's post about hitting a barrier at 36000 tiddlers, I've removed all tags from my wiki and made another typing test using a PC.

Pressing and holding a letter key produced 10 rows of text in 16 seconds in my wiki, while after removing all tags from the wiki this time was reduced to 10 seconds, an improvement in the lag by some 40% (mysterious in itself as none of the tagged tiddlers were open at the time of the test).

This might also explain why typing in empty.html is indeed somewhat faster.

-Hubert

[Mark S.]

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.

[Hubert]

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...

[Mark S.]

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!

[Hubert]

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.

[Hubert]

Mark,

I've found this old post of yours, again, in relation to performance issues specifically related to typing. This was even before TypingTimeout was a user-adjustable setting.

This led me to experiment with an altogether different approach that has tentatively solved the issue. Now I can type with no lag at all, but unfortunately this approach requires that a tiddler I'm typing into is constantly open (a 'draft of' tiddler), so as such it's a band aid approach.

The reasons behind this is that TW exempts draft tiddlers from constant refreshes or at least allows us to defer processing by a value we set in TypingTimeout, which regrettably is a value that only affects draft tiddlers (the ones that remain in editing mode).

Example code:

<$edit-text tiddler="Draft of 'text'"/>

1. Create a tiddler titled text, save it
   
2. Open the tiddler and navigate away from it (without closing it or saving it)
3. Open a tiddler with the edit-text widget and type with no lag
   

This is the level of typing experience I was expecting.

Now I have to figure out how I can prevent this open text tiddler from being constantly referenced in a red notification rectangle and to prevent TW from saving it, because once it exits editing mode the lag is reintroduced.

Regards,

Hubert

[Jeremy Ruston]

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

--
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 tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/fe01d5db-9694-480a-bb2a-bd0625a0812e%40googlegroups.com.

[Hubert]

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

To unsubscribe from this group and stop receiving emails from it, send an email to tiddl...@googlegroups.com.

[Hubert]

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

[Jeremy Ruston]

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

jer...@jermolene.com

https://jermolene.com

On 11 Oct 2019, at 14:44, Hubert <hube...@gmail.com> wrote:



To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/2c7ba11e-c57e-4189-9467-36cb1ae1213f%40googlegroups.com.

[Hubert]

Hi Jeremy,

That's fantastic, thank you! I really appreciate having this addition.

Many thanks for your support & the great work!

Best regards,

Hubert

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/2c7ba11e-c57e-4189-9467-36cb1ae1213f%40googlegroups.com.