Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loading sprites is very slow with big SVG #1342

Open
lxup opened this issue May 17, 2024 · 3 comments
Open

Loading sprites is very slow with big SVG #1342

lxup opened this issue May 17, 2024 · 3 comments

Comments

@lxup
Copy link

lxup commented May 17, 2024

Hello, for several months, I have tried many things to host my own map layers. So, I decided to test Martin. I can now host my mbtiles and also SVGs via Martin using Docker. However, when I use large SVGs (size 500x500 each one for example), accessing the sprite via Maputnik (or maplibre-gl) takes a lot of time (about 20 seconds to load an image of only 1MB). Why? Is this .png image not generated when launching the Docker container? Or is it generated on each call to the sprite URL? I need to have excellent image quality...

@nyurik
Copy link
Member

nyurik commented May 17, 2024

at the moment, every request re-generates the PNG. Caching is at the early stage of development. In the mean time, I highly recommend using nginx or varnish caching in front of Martin for now.

@lxup
Copy link
Author

lxup commented May 17, 2024

Alright, I understand better now. But why not generate the PNG image when launching the container (I ask as a student, please excuse me if I'm saying something silly haha), since to update the sprites you have to restart the container anyway? And is it possible to specify a size for each SVG (in the config file, for example)?

PS: @nyurik Is it possible to contact you to ask a few questions for a study project (its very hard to find answer for gis stuff)?

@nyurik
Copy link
Member

nyurik commented May 26, 2024

@lxup I agree it should be cached in some way. Options:

  • cache on startup, but that won't work well with dynamically combining sprites. Maybe cache just the individual sprites, but generate+cache composite ones on the fly.
  • cache on first request - probably better approach, but the first request will always take a bit longer

Regardless, caching implies that any changes to the files will not be picked up. This conflicts with the long standing #288 request - so we would need a way to monitor directory for changes, and update cache when that happens.

Sure, feel free to email me (its on my github main page)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants