Dispatcher: avoid multiple cre rerenderings when many settings changed#9651
Conversation
When a gesture/profile was updating multiple cre settings, each setting handler would emit UpdatePos which each would force a re-rendering. When this might be happening, postpone the rerendering until all are set. Needs some bit of refactoring to the events at play: introduce "DocumentRerendered" event, and use it where we used "UpdatePos" or "UpdateToc" to mean exactly that.
What's that? :o] |
| have changed (ie. font, line height, margin... change) | ||
| Note that xpointer should not be changed. | ||
| The only handler of this event should be this one. | ||
| A "DocumentRerendered" event will be then set if it has changed. |
| Note that xpointer should not be changed. | ||
| The only handler of this event should be this one. | ||
| A "DocumentRerendered" event will be then set if it has changed. | ||
| Provide force=true to get it emited even if nothing has changed. |
|
Looks good at a quick glance (but I haven't looked at the other |
Foiled by fixing a comment :D. Turns out, that, as usual, when a weird old thing doesn't make sense, it turns out the culprit is... the testsuite (adc7ddc). -_-". |
| if settings.settings ~= nil and settings.settings.show_as_quickmenu == true then | ||
| return Dispatcher:_showAsMenu(settings) | ||
| end | ||
| local has_many = util.tableSize(settings) > (settings.settings ~= nil and 2 or 1) |
There was a problem hiding this comment.
Possibly stupid idea (especially given the possible constraints on the table format): it would feel mildly more elegant to have whatever actually builds the table keep track of how many things it puts in it instead of relying on tableSize after the fact ;).
There was a problem hiding this comment.
Dunno, it's usually 1 item, or a few items, so tableSize() just doing a pair() should be quick.
Otherwise, it's for the Masters of Dispatcher @yparitcher @hius07 to say (and implement :) if it could make sense to have settings.settings.order created/removed/one-time-migrated, so that it exists only when multiple items, and absent when single item - and we could just test its presence.
There was a problem hiding this comment.
Currently one-action profile can be sorted or unsorted.
I think it would be good to disable "Sort" menu item for one-action profiles/gestures.
There was a problem hiding this comment.
But many-actions profile/gesture can be unsorted, so order field cannot be a flag here.
There was a problem hiding this comment.
And there is one more this check
koreader/frontend/dispatcher.lua
Lines 554 to 558 in d5bda32
There was a problem hiding this comment.
there are many places where we add or remove items to the table, so i think it is cleaner to have just one place where it is checked than to make sure to update some counter variable every time the table is changed. after this PR I will clean up and merge both usages into some Dispatcher:_itemsCount() function that returns a number.
|
@poire-z |
|
Here is the pidcat when I try to open patched 91: |
|
I fresh installed the 91, and then applied the first patch you provided before: #9594 (comment) It works! Profiles are applying event better now, all actions have popups and are stacked. They appear and disappear all at once. |
|
Not familiar with Android pecularities... |
|
Hmm, this is interesting. I replaced all files one by one by first making a backup of existing files, then copying the new ones from your new archive. Except from different permissions (644 instead of 600) files are not affected by anything (Unix LF is there, content is OK). Maybe my WinSCP is having problems with batch copy-replace, since before that I just copied frontend and plugins directories with "overwrite all". KOReader now works with new files too. What should I test more? Profiles' activation is instantaneous, notifications show up properly. Except that there is not notification for the font change. I have four actions in the each profile (font face, font size, font weight, line spacing), and only three notifications show up. |
|
Good!
I guess this is normal: the code that set the font does not trigger a notification, unlike all others. I guess that's because you usually set the font from the menu, so you know with the checkbox the font that you are setting, so no need to bother with a notification (displayed over that opened menu, and possible cause of the unfamous papercut refresh glitches).
Nothing specific really. Just use KOReader, tweak some setting(s) from time to time, just use it - if you don't notice any bug (like footer not updated, getting stuck), that will be fine and enough :) |
|
OK, thank you :) |
|
lgtm |
Fix regression introduced by 48eb023 #9651: on re-rerendering, the new pages count didn't reach the Statistics plugin. So, if you change font size or margins, the stats for the page read since then were badly accounted, until a change of book or restart... I noticed that in Book map, strange nobody else did over the last 2.5 weeks.
koreader#9651) When a gesture/profile was updating multiple cre settings, each setting handler would emit UpdatePos which each would force a re-rendering. When this might be happening, postpone the rerendering until all are set. Needs some bit of refactoring to the events at play: introduce "DocumentRerendered" event, and use it where we used "UpdatePos" or "UpdateToc" to mean exactly that.
Fix regression introduced by 2f749ca koreader#9651: on re-rerendering, the new pages count didn't reach the Statistics plugin. So, if you change font size or margins, the stats for the page read since then were badly accounted, until a change of book or restart... I noticed that in Book map, strange nobody else did over the last 2.5 weeks.

When a gesture/profile was updating multiple cre settings, each setting handler would emit UpdatePos which each would force a re-rendering.
When this might be happening, postpone the rerendering until all are set.
Needs some bit of refactoring to the events at play: introduce "DocumentRerendered" event, and use it where we used "UpdatePos" or "UpdateToc" to mean exactly that.
Discussion and first experiments at #9594 (comment)
Not thoroughly tested, and it's a bit hard to guess what edgy mess this kind of event tweaking can cause (I just changed what I needed trying to keep the logic, there may be extra unnecessary calls that were already there around ReaderFooter and the non-linear flow stuff). (Also, the undocumented/unavailable thru menu footer.settings.disabled=true was and is still causing a crash.)
Will remove logger.warn() before merge.
@mergen3107 : here's a zip with the files changed in this PR, thanks for testing :)
dispatcher_batched1.zip
This change is