I'm currently having the exact same problem.

I can't reproduce this on an apple silicone mbp. Are you using the latest safari? Do you have any accessibility features enabled in your OS or browser?

I just confirmed that this also does not happen on intel hardware. Can you share more information about your setup?

Same here!

Safari 16.6
macOS 13.5
MBP w/ M1 Pro

Safari Version 16.6 (18615.3.12.11.2) - Default browser - nothing installed.
Apple M1 Pro - 32GB - Ventura 13.5 (22G74)

Since I can't reproduce it, it would be most helpful if one of the affected could investigate this further. I suspect the fadeIn method somehow performs weird. Could you try and change the fadeSpeed-option to some value other than 300 and see if the behavior changes?

Hey @Mtillmann, I adjust the fadeSpeed from the defaulted 300 down to 100 and it seemed to improve the performance on Safari. There is still some slow down in the transitions, but it isn't nearly as dramatic as it was before. I also have another weird bug specific to my computer and Safari where sometimes exiting the lightbox will disable a scrolling dependency I'm using to handle scrolling behavior (Locomotive Scroll).

I've tested Safari on a few other computers and the problem is specific to this MacBook. I've also included my hardware details below.

MacBook Pro
Apple M1 Max
32 GB of Memory
Safari Version 16.4

Thanks for the report @izzy1090 , do you experience similar issues with other websites or galleriy/lightbox implementations? Does the issue also exist on the simplelightbox homepage or only in your projects environment (using locomotive scroll and other libs)?

Hi @Mtillmann, I haven't used simplelightbox or locomotive on other projects, so I can't say if it's specific to how I implemented the dependencies. The issue does not exist on the simplelightbox homepage for me.

On my end the problem only occurs on my MacBook Pro with the M1 chip(I have a MBP w/o the M1 and it's not an issue) only on Safari. The animation slowdown doesn't occur on either FireFox or Chrome for both MBP computers.

The issue with locomotive I suspect is also with the locomotive dependency as the occasional "breaks" have always existed prior to lightbox's implementation on the MBP with a M1 chip. Lightbox however does seem to invoke it as the parallax scrolling will sometimes be bypassed after exiting a lightbox.

Let me know if there is any other information I can provide!

Hi @izzy1090, thanks for the extensive feedback. Could you try once more and see if the problem can be reproduced when you set these options to false:

• disableZoom
• scrollZoom

I can imagine that locomotive may break after scrolling has been disabled and re-enabled on the document. Thanks for your time

Hi @Mtillmann unfortunately adding those two options with a false value made the slowdown more prominent. So far the best the means of speeding up the transitions is to reduce the fadeSpeed. Is it possible to reduce the fadeSpeed only on Safari?

@Mtillmann I have "solved" the problem removing the transition effects.

@izzy1090 you could try and sniff for safari and then set the fadeSpeed to a value that solves it for you.

@bmpf could you try to use will-change on the affected elements and see if it brings any improvements?

.sl-image, .sl-image img{
  will-change: left, top, opacity, transform;
}

@izzy1090 you could try and sniff for safari and then set the fadeSpeed to a value that solves it for you.

@bmpf could you try to use will-change on the affected elements and see if it brings any improvements?

.sl-image, .sl-image img{

  will-change: left, top, opacity, transform;

}

Thank you! Targeting Safari and making the fadeSpeed 0 helped reduce the sluggish performance. If you're ever able to replicate the issue on Safari and fix it, let me know! I like the fade transition and would love to have a consistency between all browsers.

@Mtillmann i just noticed same issue on Safari 17.0 monterey 12.7. After some quick debug i can confirm following:

1. It does not depend on os version as Sonoma 14.0 - same result
2. When you first open the gallery it is like 2 frames per second. You close it and open again - works much better. But if you scroll slides too quickly it just freezes and can not be closed.
3. It looks like not css related issue, as with removed css it is broken but still freezes, Chrome works fine. "will-change" property makes no effect.
4. Reducing fadeSpeed does not resolve the issue, just makes it less prominent. Still freezes on quick slide change.
5. Preload does not affect the issue, with "preload": false same result.
6. This one is very strange. When it freezes opacity value on slides is always stuck to same value 0.055556 and does not go higher. I believe it can be something related to numbers rounding in Safari. I had no much time to dig deeper in the code, but what i tried - i replaced in sources number 16.66666 with 16in fadeIn and fadeOut functions and it started to work much better, at least it does not freeze at all.

@Taras-R thanks for you in-depth analysis. Could you try and dump more of the vars in the function where you changed the float? maybe some value is too small to make the fade work corrrectly.

@Mtillmann few more things i can add after closer analysis. It depends on what monitor you open the lightbox. When i open it on in-build mac retina it has significant delay between actual sliding animation and fade. Sliding performs quick and as it should be but fade is much longer. When i just move the window to external non-retina monitor all animation timings seem to be in sync. The only difference i see is that fadeIn and fadeOut are achieved with requestAnimationFrame approach, at the same time translate is performed with transition.

Maybe it is because of pixel density, maybe refresh rate, poor performance and timings out of sync seem like requestAnimationFrame caused. But it is Safari issue for sure as in Chrome everything works fine no matter what monitor it is in.

@Taras-R You might be on to something here, the fade function is currently not dependent on time, but on steps. MDN has this to say about requestAnimationFrame:

Warning: Be sure always to use the first argument (or some other method for getting the current time) to calculate how much the animation will progress in a frame — otherwise, the animation will run faster on high refresh-rate screens. For ways to do that, see the examples below.

Not sure why other browsers do not have a problem here, but I noticed Safari is maxing out my CPU while fading, whereas Firefox is picking its nose during the fade.