-
Notifications
You must be signed in to change notification settings - Fork 310
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
SVG plugin not working #687
Comments
well...png doesn't work either...I guess there must be something wrong with the render backend. |
Haven't really seen this. It is working well on my end. I see that I have lunaSVG 2.3.8 installed, so maybe you can try that and see if there are some differences? As for PNG, note that our built-in renderers only support uncompressed TGA out of the box: https://github.com/mikke89/RmlUi?tab=readme-ov-file#renderers It is fairly trivial to add your own image types though. See for example how that is done in the SDL_GL3 backend here. |
Also, ensure to check the log output for any messages there. |
yeah I've checked, no error, no warning |
uhhm that's so sad |
I guess the library tries to be compact by functionality and by output size. So adding libraries means growing in size. If there is a lightweight version of crossplatform universal image handling library I would welcome a such solution. At least there is DirectXTex but it is for windows. (Is it lightweight?) Also adding new types of images make harder to maintain library. Remember we don't have only one graphics backend we will have 4 at least. I just suggest to provide image callback for any backend and user can specify on its side what library to use and how the image to process. Indeed a such idea was provided in DX11 backend and I will add in mines. |
I don't really think supporting more picture format would make the library harder to maintain. All the formats should be converted to the raw format before making them a texture, and the process of making a texture from a raw image is the same. |
If binary size really matters, I guess we can make it optional, like what we did for SVGs. |
Yes, we have libvips: https://github.com/libvips/libvips |
It also modularized, so the requirements of binary size can be meet. It even supports SVG. |
First of all, I want to remind you of the overarching philosophy of our library, from the readme:
Instead of meeting every requirement for every user, we make a highly modular API, where it is easy to extend features and customize the library to their needs. This is a core idea to the library, so that we avoid feature creep and bloat for users that don't need it. This also relates to #450. Did you take a look at the example I linked earlier to add support for other image types? It's literally 50 lines of code. |
Yes, it's great. But since we already have SVG support as a plugin, why not other format? It won't even take up extra space if the user do not enable it. |
That's fair enough. Our plugin system doesn't currently fit well for image types though, since images are loaded in the backend. So we would possibly have to devise some new API. Which also might be a bit confusing considering that we already have an existing API through the render interface. I'll keep this in mind for the future, but for now this is not a high enough priority to be worked on, if this is something we want at all. Especially considering that the solution requires I would say relatively low effort from users, and we already serve examples on how to do it. |
any idea? no error in the log. GL3+GLFW & LunaSVG latest
The text was updated successfully, but these errors were encountered: