[REACT] pinch zoom on iOS

[calendardeveloper]

https://stackoverflow.com/questions/76127296/debugging-a-ios-safari-crash-a-problem-repeatedly-occurred

Question for Bryntum team,
Based on the above, it could be related to the high GPU usage, is there anything in that article that stands out? Can you think of any CSS/JS code that might be causing this?

[nickcc]

Thanks Anuj,

There is certainly a lot of food for thought in that article and a good number of leads as to where to go looking for the causes and potential fixes/mitigation.

Fingers crossed that one or more of them will come up trumps and this can be sorted out.

Nick

[alex.l]

Hi,

I've opened a bug for Apple. We will keep an eye on updates https://bugs.webkit.org/show_bug.cgi?id=276057

[calendardeveloper]

Hey guys,

I have been digging into this and I found out that the crashing really only starts once we have more than 900(ish) rows in the scheduler. Anything up to 500 is not crashing as much and is actually usable.

So, my question is, given that we have row virtualization implemented, why would it matter if there's 500 rows or 900 rows or any number of rows really? Are there any config settings that can be used to optimise this? Is there something happening internally that might be tripping up the virtualization? Or is it the fact that it has to process that many events/resources even if they are not visible?

Is there a way to not throw all 900 rows of events/resources (Each row can have 20-30 events) at the scheduler all at once?

[alex.l]

Hi,

Will it be easier to reproduce if you enable CPU throttling and use 500 rows?
Actually, vitrualization will not render all 900 rows at once, you can compare amount of DOM elements.
https://stackoverflow.com/questions/9808307/how-to-get-the-number-of-dom-elements-used-in-a-web-page
That might be something else that avoid on it, some other calculations maybe.

[calendardeveloper]

I am not sure what you mean? I know virtualization will not render all the rows and that was exactly what my question was. It should not mater how many total rows there are because virtualization will only render what can be visible in the viewport (plus a buffer). So, that leads to my question then...why is it crashing then? why does it stop crashing when I have only 100 rows (and only 50 are visible) vs when I have 700 rows (and still only 50 are visible)...is there something that can be improved in how virtualization handles the rows internally?

[alex.l]

I have no idea actually, I can't debug page when it crashed. That's why I asked to compare amount of DOM elements, maybe that's side effect and the problem is not in DOM, but in internal processes. I suggested to test it: try to compare DOM elements count, and try to decrease performance.

[nickcc]

Hi,

I've opened a bug for Apple. We will keep an eye on updates https://bugs.webkit.org/show_bug.cgi?id=276057

I saw the ticket with apple. Nothing from them for about 2 weeks now. The example you gave hardly has many rows and doesnt crash very often. Can you increase the number of rows so they can see it crashing regularly on zoom. Otherwise they may come back and say nothing is really wrong.

I am not sure if this issue may lie in the virtualisation in your software instead of in the browser webkit?

Do you know when 6.1 will be released with pagination?

Also what are the plans for your own Zoom project that Mats was talking about.

We are desperate to somehow get this crash on zooming issue resolved and still not certain where exactly the issue lies.

Is it worth putting more rows in your example so it definitely crashes and asking Apple where they are at with it?

[nickcc]

https://stackoverflow.com/questions/76127296/debugging-a-ios-safari-crash-a-problem-repeatedly-occurred

Question for Bryntum team,
Based on the above, it could be related to the high GPU usage, is there anything in that article that stands out? Can you think of any CSS/JS code that might be causing this?

Alex,

What about asking that "milehighsi" guy on that stackoverflow thread to look into it for you? He may be able to see what is causing the issue. It might just be something relatively simple. Would be good to have these large datasets working reliably on iphone Safari and it sounds like he is on the right track and has led other folk to solutions around this.

[nickcc]

I see you guys have the safari pinch zoom crashing as an open ticket here
https://github.com/bryntum/support/issues/8928
and that another of your users was having exactly the same issue back in early April.

I can see that Mats has chased Apple on it last week on their webkit bug page.
If it can be solved then we won't need to do all the work we are doing around pagination to get around it (for the time being).
It is a really annoying one and I am sure we are all equally keen to get to the bottom of it! wherever the issue lies as iphones are the main mobile device out there and there will be plenty who need to reliably use big datasets.

Again I am not sure how the zoom project you are doing is coming along and if that will then handle ios zoom in a different way and get around the webkit issues that way. I sent a few videos to Mats of what our ideal zoom solution would look like and it sounds like done well it could certainly kill quite a few birds with one stone...

Thanks for the efforts.

Nick