SVG plugin not working

[std-microblock]

any idea? no error in the log. GL3+GLFW & LunaSVG latest

[std-microblock]

well...png doesn't work either...I guess there must be something wrong with the render backend.

[mikke89]

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.

[mikke89]

Also, ensure to check the log output for any messages there.

[std-microblock]

Also, ensure to check the log output for any messages there.

yeah I've checked, no error, no warning

[std-microblock]

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.

uhhm that's so sad
why not consider adding a real png parser, libpng for example, to provide full support for pngs?
also how about webp?

[wh1t3lord]

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.

[std-microblock]

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.

[std-microblock]

If binary size really matters, I guess we can make it optional, like what we did for SVGs.
Tho I think as a basic functionality for ui libraries, it should be default enabled...

[std-microblock]

Yes, we have libvips: https://github.com/libvips/libvips
This.is what chromium used to handle images. Its stability and performance have been proved.

[std-microblock]

It also modularized, so the requirements of binary size can be meet. It even supports SVG.
I strongly suggest using it to implement support for more images.

[mikke89]

why not consider adding a real png parser, libpng for example, to provide full support for pngs? also how about webp?

First of all, I want to remind you of the overarching philosophy of our library, from the readme:

RmlUi aims at being a light-weight and performant library with its own layouting engine and few dependencies.

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.

[std-microblock]

why not consider adding a real png parser, libpng for example, to provide full support for pngs? also how about webp?

First of all, I want to remind you of the overarching philosophy of our library, from the readme:

RmlUi aims at being a light-weight and performant library with its own layouting engine and few dependencies.

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.

[mikke89]

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.