Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Device crashes when <Svg> is too wide
See original GitHub issueBug
Device crashes when <Svg> is too wide
Unexpected behavior
<Svg width="21489" >
Above code crashes using Expo on my Nokia 9 PureView.
Works fine on iPhone simulator.
Best, Andy
Issue Analytics
- State:
- Created 4 years ago
- Comments:22
Top Results From Across the Web
Device crashes when <Svg> is too wide · Issue #1302 - GitHub
I was surpised to see that using this library with expo that an SVG size of over about 1200x1200 causes an app crash...
Read more >SVG Transition is crashing chrome (css, html) - Stack Overflow
The issue is a browser bug. Here is chromium's bug tracker. Let them know about it. Note that I could repro in both...
Read more >Complex SVG is rendering slowly and freezes the page
The svg element should update its position with a fast interval without lag. What went wrong? The page freezes, and the svg element...
Read more >Constant crashing on SVG export : AdobeIllustrator
1. The Export function, which is obviously broken for you. · 2. Choose Save As and select .SVG from the Save as Type...
Read more >RESOLVED: IX 2 performance issues and SVG not uploading
Hello webflow, Since 2 months I I have been working on webflow very often (to make my own website), ... Chrome crashes right...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I really do not think I have enough knowledge about the underlying structures to suggest a Pull Request. But this should be handled in a more gracefull way. I almost consider this one useless as is. And really, I know you can blame Android for their poor implementation, but also errors can be handled in this project but not in projects using this project.
A pr is a pull request, i.e. a request to merge a proposed fix for the issue. I don’t think it makes sense to render anything at all if the request memory is unavailable. Logging an error of some sort probably makes sense, ideally some catchable error event such that the author can decide how to handle that there is not enough memory on the device.