Device crashes when <Svg> is too wide #1302
Comments
|
This would probably happen even in a native android java app, if you tried to create a bitmap of that width on that device, and nothing else, in similar memory conditions. Would probably be better not to crash though. Mind making a pr? |
|
It actually fails at 3400. What is a pr? |
|
@msand not failing would be an upgrade. I got it in a thread over here at Expo: If it would be possible to select either trimming down to a certain width, height or proportional size it would be even nicer. Cant really handle those errors in Expo ...as far as I know. Best, |
|
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. |
|
Well yeah it's a Android problem. But am surprised it is drawing bitmaps and also not internally being able to cache instead of throwing errors. Not sure how errors could be handled gracefully in this context though if not drawing anything. |
|
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. |
|
I'm not sure what you mean, isn't the issue that you're trying to make an svg which is several times larger than the screen, even so large that it wont even fit in memory, the main issue? Why would you even need a bitmap much larger than the screen? Seems more like a bug in your use of svg rather than something that could even in theory be fixed, at best it can not render at all and throw an exception / call an error handler. Do you expect it to expand the amount of hardware inside the device when you request to allocate too much? |
|
I do not considder it an issue that I'm making an Elevation Chart that scrolls sideways and are bigger than the screen size. I consider it an issue that the component crashes the system on Android if for whatever unknown issue it is not able to handle it. iPhone do not have a problem drawing it. It is not a bug in the use of the SVG. The problem only exists on Android, because the way Android implements it, and the component layer is not handling it garcefully. |
|
I recommend you study how memory and bitmaps work, and how the amount of memory, not the os, is the deciding factor. |
|
You can certainly make it bigger than the screen, but not bigger than available memory. |
|
Anyway, you're doing it wrong. I'm informing you this as the maintainer of the lib. Ignore at your own peril. |
|
I did study how the memory works on Android and they have a 100 MB limit on bitmaps. It might crash before the 100 MB though. I can currently make it 5 times bigger than the screen on Nikia 9 PureView. But is it not possible to make a pure vector based implementation on Android? It would most likely save a lot of memory. |
|
And yes, trying to do what you want the way you are is as you say "useless", not supported, and most likely never will be. Use a screen sized bitmap, and transform the content instead, or split it into smaller pieces and use a flatlist or something. |
|
I think I'll try spending my time on Flutter instead. Seems like they have better vector support. |
|
Good |
|
If I get you right, I should just make one big Svg on iPhone and on Android I should make a lot of small ones and make something like a ScrollView? That's the right way to use Svg according to you? I think that shold be handled in the Svg component. But as you think it is a mistake to make big Svg's I'm pretty sure that is not going to happen. Right? |
|
No, use a single svg view, the size of the screen, have infinite content inside, use transforms to move it around. |
|
Only if you insist on rendering lots of pixels offscreen you could make several views, I don't know how or when that would make sense though, but if you insist on rendering more content than the user can see, and spending battery on that, you can draw as many redundant pixels as the device restrictions allow you to. |
|
Alternatively if you want to oversample the rendering it might make sense, but seems mostly reasonable for creating png:s for display on larger screens. It wont make the rendering on the phone any higher resolution than the actual screen anyway. I see no good reason for having much larger bitmap than screen size. Why would you sacrifice the user experience that way? Would just make almost everything take much longer. |
|
I was surpised to see that using this library with expo that an SVG size of over about I appreciate the discussion above, but I'm just as lost on how to best achieve my goal of offering lines drawn on mobile atop a background image, that stay in position. My only idea at the moment is adjusting the I'd appreciate any insight, however trivial or small. |
|
@mrousavy Have a look at comment: #926 (comment) . The solution is to have the svg be at most the size of device view, and transform the content in response to touch. There is also a good example from msand that sounds like your desired use case of lines atop an image linked to here: #573 (comment) in the Soundcloud player example |
I ended up just using a WebView and adding a SVG to that. Works like a charm. |
Bug
Device crashes when 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
The text was updated successfully, but these errors were encountered: