Skip useless tasks in the worker to improve fast scrolling with scanned books (bug 1866296) #17403
Conversation
calixteman
force-pushed
the
rm_cancelled_jobs
branch
from
db6d087
to
a85b8bc
Compare
…ed books (bug 1866296) When a page rendering is cancelled, a task is sent to the worker but before it's executed the rendering task is: the cancel task is more or less useless in this case. So in using the fact that draining the message queue has a higher priority than draining the event one, it's possible to get all the current tasks, hence it's possible to cancel some tasks which are before a cancel task.
calixteman
force-pushed
the
rm_cancelled_jobs
branch
from
a85b8bc
to
c0ee0ba
Compare
There was a problem hiding this comment.
Sorry, but I still consider this really risky since if (or dare I say when) there are problems with this they are going to be highly timing-dependent and thus extremely difficult to debug.
Furthermore, based on a very quick look, once you set this.#isPostponed = true; there's nothing that ever resets it so I don't really understand how this won't also affect all sendWithPromise-calls that happen after the first sendWithStream-invocation?
Could we perhaps try my viewer-only approach first, and see how that behaves in real-life scenarios, since it should be very low risk compared to this?
|
This (or something along these lines) could be a nice win on mobile where fast scrolling is very frequent on long documents. |
When a page rendering is cancelled, a task is sent to the worker but before it's executed the rendering task is: the cancel task is more or less useless in this case. So in using the fact that draining the message queue has a higher priority than draining the event one, it's possible to get all the current tasks, hence it's possible to cancel some tasks which are before a cancel task.