CollaboraOnline
Impress slideshow performance: getting less of the spinner ...
Describe the Bug
The profile suggests that dumb stuff like rendering the spinner is unfeasibly slow, as pointed out by @mmeeks, - @codewithvk should connect with Chris ( @Cwiiis ) - and they should look at the profile together there is something incredibly poor about that
Current spinner profile
Possible improvements I see:
- We start the loader, then fetch slides via
displaySlideand wait for the server response from CoolWSD- Idea: what if we initiate the socket call for
displaySlidebefore starting the loader and other processes to offload it?
- Idea: what if we initiate the socket call for
- Async code might help here?
Not sure about other aspects, maybe @Cwiiis can help find the reason?
Interesting, yours looks like we wait on the server for half the time - mine looks like constant grief. Glad spinner rendering is not causing problems for you.
We should take some obvious steps here I think.
I suggest that after the JS UI has tiles to render the current view, and thumbnails for the slide-sorter - we should:
- fetch the slideshow information before it is requested
- when not-busy in the UI - fetch the master-page layers for each master-page and cache them for our screen-size - everyone presents full-screen in the real-world I think and interpolating down is fine as a 1st cut
- compile shaders for the first slide transitions in the background too - on a worker to avoid multi-second hangs.
Hopefully this saves us enough time that we can start way faster by the time we get there ;-)
Thanks !
Progress so far:
- Fetched slideshow info before initialization – Done (for prototype).
- Preparing slides for presentation and caching them in advance – Almost done (for prototype).
- Had a question about how to determine if we're not busy: - For the prototype, just planning to add an async call just after fetch slide thumbnails.
Next:
- In debug mode, replace pre-fetched (cached) slides with the slideshow ones.
- Analyze performance and explore possible improvements.
- Pre-compile shaders
cc: @quikee @pedropintosilva
Current Status:
- Successfully pre-fetched presentation info before starting. Track tile updates as well...
- We'll check if the master slide hash already exists or not. If not, then we'll queue it.
- Queue master slide fetching via traditional route
Next Tasks:
- Need to test and validate the idea: Create ImageBitmap via web worker (01 PD)
- Possible Problem: Transfer created bitmap to main thread?
- Quick reference: https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/
- Instead of queueing slide fetches - just download slide, convert it, then fetch next slide (1/2 PD)
- Show 1-2px progress bar at bottom of presentation which represents how many slides are pre-cached... e.g., (5/12) cached... (2/3 PD)
- Based on Web worker idea : - Not Sure so test : "de-compressing the compressed tiles and the ImageBitmap creation"... (2-3 PD)
- Cache images in their compressed form, not as ImageBitmaps (let's say 5 PD)
- Pre-compile shader code? (0.5 - 1 PD to research the code, ballpark 5 PD)
This is a good place for next steps: so - we should drop the ARGB swap that takes CPU time on the server before the zstd compress (as we do for tiles these days) - and do that in the JS or (ideally) not at all as we create the image as Chris does. Ideally we can re-use @Cwiiis existing web-worker logic there which is used for tiles (but of course our tiles are not RLE'd only zstd'd (which is prolly for the best) - hopefully that is reasonably easy - we need of course to work in a world without working web-workers too. I expect the web worker to stop stuttering during animations by moving slow / JS thread blocking things out of the main rendering thread and to be one of the biggest wins.
