-
-
Notifications
You must be signed in to change notification settings - Fork 219
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
feat: add sdf
sprites via additional apis
#1492
Conversation
4342a85
to
8fc96b4
Compare
sdf
file conversionsdf
file conversion
…g for this feature
2db4897
to
947bc6e
Compare
Thanks, this is an awesome feature to have. One thing I kept thinking while reviewing: would it be possible to NOT have any of the associated config values, and instead simply allow both sdf and non-sdf usage? It's not very difficult to run through the TBD:
|
Honestly: I need to look into if this is possible, but I think we could just activate this automatically if users are using monochrome icons. Using a different url is fine too. Will have to test if this would be a breaking change though ^^ Answering your questions:
Yes, thinking about it, I can see a reason why one would want both (multi colored and dynamically colored icons on the same map)
In any case, I need to make this more clear in the docs, why one would choose the one or the other image format. |
Hi 👋🏻, chipping into this nice PR because it would be very helpful for improving the symbol rendering one of my projects using the MapLibre stack (https://github.com/hiddewie/OpenRailwayMap-vector).
Testing the output from the
while
(colorless and with the distance field visible). So the Martin SDF sprites should output something similar when using the spreet library.
It would be useful for me to have both normal and SDF sprites output and available for map rendering. The first thing I can think of is rendering the same symbol twice, one SDF with the icon outline, and the colorful icon on top to automatically generate a (fixed color) halo around a symbol. And the other reason mentioned above, to render both colored and monochrome variants of the same image on the map is also useful. The combination of a colorful image together with the SDF data would be ideal, but I don't think that is supported in a single sprite image by any of the libraries or SDF sprite consumers. Maybe there could be a way to change the consuming map rendering libraries to accept two paths of the same sprite resource, one for a colorful image, and one for the SDF image, and the rendering library could combine the information to render colorful icons together with an icon halo. |
sdf
file conversionsdf
sprites via additional apis
That was user error. Thanks for noticing, that feature would have not worked. I have raised a PR documenting the behaviour upstream flother/spreet#85 and fixed the bug in my code ^^ |
|
||
Ok((name, sprite)) | ||
} | ||
|
||
pub async fn get_spritesheet( | ||
sources: impl Iterator<Item = &SpriteSource>, | ||
pixel_ratio: u8, | ||
as_sdf: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Attention: There are 2-3 semver-breaking changes here.
Without reworking the API completely, I don't see how this can be avoided.
=> @nyurik would a major version bump be okay?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we are totally ok to keep bumping major for martin - no biggie
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks better with each pass!
WRT url - i'm still a bit on the fence on the API... /sprite/sdf/...
does make sense, but then you have to handle if the user gives a sprite source named sdf
(which probably is not that unusual)... On the other hand, a source called /sprite_sdf/...
or /sdf/...
or /sdf_sprite/...
keeps naming collision resolution in one place (we already do this for sources), and keeps overall pattern consistent (no URL sub-branches). I would prefer to keep API flatter, just not sure of the naming.
|
||
Ok((name, sprite)) | ||
} | ||
|
||
pub async fn get_spritesheet( | ||
sources: impl Iterator<Item = &SpriteSource>, | ||
pixel_ratio: u8, | ||
as_sdf: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we are totally ok to keep bumping major for martin - no biggie
Co-authored-by: Frank Elsinga <[email protected]>
Have changed it to The reason why I introduced it as
https://actix.rs/docs/url-dispatch/#generating-resource-urls => even if a sprite was previously named |
Thx for changing - i do think it looks a bit better now, but if anyone has other thoughts, please chime in. @CommanderStorm could you add some tests to the test.sh? Make sure to run |
Shure thing, have added it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome work!!!
Great work @CommanderStorm, this gives nice results on my maps! |
Uses maplibre/martin#1492 Unfortunately, SDF sprites cannot be layered right below each image, they have to be in their own layer below the icons. Symbols with outline: ![image](https://github.com/user-attachments/assets/da290ed7-441a-4c88-881a-88ee845d3acf) Hovering on rail lines in their native color: ![image](https://github.com/user-attachments/assets/79556b75-e6ab-4c37-95d6-87c9d22264ab) Railway direction including hover: ![image](https://github.com/user-attachments/assets/fe071904-2e9d-450f-8f63-e0613c8ac515)
Resolves #1075
I am not quite right if I have made everything correctly.
The project has lots of places to configure things and it was not always clear where I need an Option.
Another thing which is likely wrong:I'd assume as far as I read the blessing that should require new files...
Something is really odd here => need to debug that before public review makes sense
I fucked up the testcase a bit. This is now fixed