Reduce CPU consumption of Entry cursor by around 80% #4560
Conversation
saves CPU but gives a nice fade feel instead of sharp on/off
widget/entry.go
Outdated
| func (e *Entry) Refresh() { | ||
| e.propertyLock.Lock() | ||
| e.minCache = nil | ||
| e.propertyLock.Unlock() | ||
|
|
||
| e.BaseWidget.Refresh() | ||
| } |
There was a problem hiding this comment.
I'm not saying that it need to be done now or should be done, but maybe it would make sense to have some kind of MinSize cache built in to the basewidget? I suppose it is something we might want to do for all widgets more or less (unless the computation is very cheap).
There was a problem hiding this comment.
I did propose the BaseWidget inclusion some time back but there was pushback for a reason I cannot recall.
Let's get it in here and see how useful it is and it could be pulled up without impact later.
There was a problem hiding this comment.
It might be worth exploring again. Either as part of the base widget or as some kind of ready cache-system that developers can add to their widgets (maybe using async.Size internally?). We should at least look at caching MinSize in more widgets :)
|
This should be pulled into v2.4.5 if possible as it's another huge optimization, but like the one for animation runner, it may need minor reworking to not use |
|
It might be worth just waiting for v2.5.0 if the changes are as big as they are |
I think it might just be undoing the last commit 42ab4dd Plus, if the new threading model is landed in 2.5, which is the current plan, async.Size may not even be needed anymore as widgets can assume their API calls would arrive from a single thread |
|
This is a huge optimization for any Fyne app where the user spends any non-trivial amount of time in text entry. I think we really should get it in 2.4.5 |
Description:
Reduce CPU load by around 80% by fading over only 1/5th the time.
Also avoid re-calculating MinSize when the visible content has not changed.
Fixes #1946, #4156
Checklist: