thorvg
Using viewbox tricks to zoom in on very big SVGs causes a freeze.
I'm making a vector graphics application and while I can't reproduce this, Windows users have given me reports that they get freezes while they zoom into graphics.
In order to implement infinite zoom in my app, I re-render the visible part on each frame, using an adjusted width-height-viewbox. However, some users have reported issues with this. Of the four people who I tested this with (plus myself), the two Linux users weren't able to reproduce it, but the three Windows users were able.
Test SVG: <svg width="37.432" height="37.786" xmlns="http://www.w3.org/2000/svg" viewBox="431.158 533.026 37.432 37.786"><path d="M1000 0 0 1000"/></svg>
One of the users tried to paste this SVG into the ThorVG viewer.
Another user tried to load the SVG using Godot and got a permanent freeze:
func _ready() -> void:
print("Starting")
for _i in 3:
await get_tree().process_frame
var svg = """
<svg width="37.432" height="37.786" xmlns="http://www.w3.org/2000/svg" viewBox="431.158 533.026 37.432 37.786"><path d="M1000 0 0 1000"/></svg>
"""
var img = Image.new()
var err = img.load_svg_from_string(svg, 22.627) # 22.627 is a scaling factor that should result in a 700x700 image, nothing too intense.
print("Finished")
I would like to add some more info. I hope it helps:
- It scales with size. The larger the line becomes the sooner it will freeze/crash when zooming in
- There is a significant CPU usage when panning around (Both Linux and Windows)
- it specifically only happens with a diagonal path vector. Anything else seems to work fine
There is a significant CPU usage when panning around (Both Linux and Windows)
In the case of my app, it's because the graphic is redrawn every frame when you pan around. But that might be a side effect of ThorVG being way slower than one would expect.
There is a significant CPU usage when panning around (Both Linux and Windows)
In the case of my app, it's because the graphic is redrawn every frame when you pan around. But that might be a side effect of ThorVG being way slower than one would expect.
@MewPurPur @Racer911dash1 May I ask what the resolution of the SVG image is in that case? To the best of my knowledge, Godot should have a completed image from ThorVG and should not request a redraw during panning. Otherwise, at the very least, it should apply viewport(canvas::viewport()) drawing for the optimal visible area.
+ @akien-mga @fire @capnm
I think there's a misunderstanding. This is specific to how zooming works in my vector graphics application. In order to implement infinite zooming, I take the SVG text, modify its width, height, and viewbox, and only parse this modified SVG text. If I didn't do this, I would have to render ginormous images and suffer extreme lag spikes, and infinite scaling also wouldn't work because at some point I'd hit the limitation of 16384x16384.
The SVG text in the original post is an example of what the modified width + height + viewbox could look like when you zoom into a big image. But that SVG itself isn't truly zoomed in, it's just a rectangular cutout of the bigger SVG.