You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This ticket just some clarification about svg, and maybe more explicit api.
So backstory, I noticed svg render was empty sometimes; i then realized i was passing path with typo, and svg (presumbly) wasn't loaded, but no error.
Ideally, I handle loading raw bytes of svg once with regular file into vec<u8>, and pass this to svg api constructor. Maybe similar to #76 ?
I only see path api in svg though, unless I'm missing it? This also makes me wonder, is svg loaded from disk by iced and cached somewhere? I prefer to be in control of resource loading, so:
can we have explicit from_bytes (or whatever) api for handling resource loading ourselves
less ideal: can we add error (or panic at least) if file not found for svg api (probably error is harder because the actual loading is done by something else in iced?)
and thanks for great library :))))
The text was updated successfully, but these errors were encountered:
Yeah, I’d +1 being able to load SVG directly from bytes. This would be extremely useful for cases where the svg is generated in the program on the fly. Currently I’d have to save to file and reload from the known location which feels very hacky.
This ticket just some clarification about svg, and maybe more explicit api.
So backstory, I noticed svg render was empty sometimes; i then realized i was passing path with typo, and svg (presumbly) wasn't loaded, but no error.
Ideally, I handle loading raw bytes of svg once with regular file into
vec<u8>
, and pass this to svg api constructor. Maybe similar to #76 ?I only see path api in svg though, unless I'm missing it? This also makes me wonder, is svg loaded from disk by iced and cached somewhere? I prefer to be in control of resource loading, so:
from_bytes
(or whatever) api for handling resource loading ourselvesand thanks for great library :))))
The text was updated successfully, but these errors were encountered: