Impress: slide transition performance ...

[mmeeks]

The clock wipe (and I guess other transitions) are -unfeasibly- slow - WebGL should be able to render five triangles and adjust the hands here at 120fps without breaking even a small sweat. How is it there are only 10 jerky frames here - we want a smooth beautiful transition =)

Surely we have some requestanimationframe or whatever that gets a proportion of the distance through the ... ? not sure how it ended up like this. Would love to read the patch that fixes it.

Thanks !

jerky-clock-wipe.odp

[codewithvk]

PR's should solve this Issue: #11986 #12001 #12036

[pedropintosilva]

I'm closing this as it has been fixed. To test it a monitor with a high frame rate should be used (higher than 60 fps, ideally 120 fps)

The rationale is in the PRs, example:

• fix(slideshow): avoid jerk during transitions by queuing slide layers fix(slideshow): avoid jerk during transitions by queuing slide layers #12036 : while rendering the transition we were in the we were combining the layers for the next slide and with this fix we now have:

When a transition is active, incoming slide layers are now queued and only processed after the transition ends. This prevents visual glitches caused by prematurely rendering new slide content mid-transition.

• with https://github.com/CollaboraOnline/online/pull/11986/files we also don't limit the frame rate to 30/60 fps anymore

[codewithvk]

Thanks @pedropintosilva for the reply, I have more to add here

• with https://github.com/CollaboraOnline/online/pull/11986/files we also don't limit the frame rate to 30/60 fps anymore

PR #11986 was supposed to increase the preferred framerate to 60fps and the highest framerate to 120fps. However, this applied to both animation and transition. Later, we created PR #12001 to skip framerate adjustments for transitions only, while animations continue to use the older limits.

so now, transition should work smoothly regardless of frame rates :)

[mmeeks]

I get from 5 to 8 FPS on my local machine for wheel wipes. No idea why.

Can we ensure the sample presentation in the source tree has some more challenging 3D transitions - it seems to do checker dissolves - which are extremely blocky (surely we can fade & dissolve in a sexy way too even with these squares ? =).

Ah - seems I have hardware acceleration off - so I'm prolly using software OGL =)

[mmeeks]

Much better with hardware acceleration enabled. I wonder ... is that something we can detect from JS with some reasonable reliability and without new dependencies. Quite possibly we should fall back to just cuts in this case =)

[eszkadev]

@mmeeks there is a fallback, we check if webgl is available, if not - we use 2d without transitions.
We have separate renderers for it: https://github.com/CollaboraOnline/online/blob/master/browser/src/slideshow/LayerDrawing.ts#L330

But possibly there are some more detailed options to check https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API