Transformation via style attribute possibly causing performance issues in iOS

[davidrapson]

Expected behaviour

Smooth panning on iOS

Actual behaviour

Noticeable lag when panning on iOS

Description

I've been experiencing some issues with performance when panning large SVGs in iOS since the switch to applying transforms via the style attribute

This issue sounds like it could be (possibly) related to #223.

Steps to reproduce the behaviour

1. Panning large SVG
2. Panning handled using Hammer.js
3. On iOS using svg-pan-zoom version 3.2.7 and above panning becomes laggy

Configuration

• svg-pan-zoom version: 3.2.9
• Browser(s): Safari
• Operating system(s): iOS 10

Current Solution

I've currently resolved this by downgrading to 3.2.6.

It's worth noting that this is most noticeable for large SVGs so a possible solution could be a flag to opt-out of style attribute transforms.

Next steps

I can create a reduced test case to demonstrate this. Would you prefer that I close this issue and re-open when I'm able to provide a demo of the issue? Whatever is best for you.

[ttupper92618]

Have not had time to try, but perhaps try using translate3d with webkit to force hardware acceleration.

See comments and code block on e1239d4

[bumbu]

Hi @davidrapson
Leave this issue open, and please provide a simple test case (preferably an online demo on jsfiddle or similar services).

Would be best to find a way to keep current functionality while providing good performance on all supported browsers.

[ariutta]

I'm pretty sure you're right, @davidrapson, that what you're seeing is the
same issue as #223.

@bumbu, could the solution be as simple as detecting whether environment
is iOS and if so, using the old way (transform via attribute instead of
style)?

On Oct 23, 2016 4:23 AM, "bumbu" notifications@github.com wrote:

Hi @davidrapson https://github.com/davidrapson
Leave this issue open, and please provide a simple test case (preferably
an online demo on jsfiddle or similar services).

Would be best to find a way to keep current functionality while providing
good performance on all supported browsers.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#224 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPJg6pktzZNKCHhrSq-1lglVKS_MlFUks5q20O_gaJpZM4KU616
.

[davidrapson]

@bumbu Thanks, I'll try and pull together a jsfiddle within the next few days.

[bumbu]

@ariutta from what I remember updating via style was added to all browsers in order to allow CSS animations (#195). So simply getting rid of that will break that behavior. A better solution would be to have an option for that (for not using style attribute).

[Yimiprod]

Maybe instead of transform: matrix(...) using transform: matrix3D(...) could help?
Or add translateZ(0) in src/svg-utilities.js#L149
Either way, force hardware acceleration.

[ariutta]

@bumbu is more familiar with this issue than I am, but the biggest thing is
to identify which browsers (and OS's, if that matters) to support and then
test to verify the proposed solution works. Is there a way to test whether
hardware acceleration is working by using something like Selenium? Test
services like sauce labs might be useful here.

On Nov 10, 2016 1:05 AM, "Vidril César" notifications@github.com wrote:

Maybe instead of transform: matrix(...) using transform: matrix3D(...)
could help?
Or add translateZ(0) at https://github.com/ariutta/
svg-pan-zoom/blob/master/src/svg-utilities.js#L149
Either way, force hardware acceleration.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#224 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPJg7rZViRq1x1RuwfxOs-gns701cooks5q8t5agaJpZM4KU616
.

[Yimiprod]

By the way, it look like setAttributeNS can trigger transition if we don't specify the animation target:

transition: 300ms ease-in-out

[bumbu]

@Yimiprod nice catch. Does it work like that in all supported browsers?