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

optionally use stb_image and nanosvg #242

Open
technosaurus opened this Issue Nov 4, 2015 · 5 comments

Comments

Projects
None yet
2 participants
@technosaurus
Contributor

technosaurus commented Nov 4, 2015

I wrote a small patch to use https://github.com/nothings/stb/blob/master/stb_image.h
(for smaller static builds using musl-libc, but it does support some additional image types)
It supports the following image types:

 JPEG baseline & progressive (12 bpc/arithmetic not supported, same as stock IJG lib)
  PNG 1/2/4/8-bit-per-channel (16 bpc not supported)
  TGA (not sure what subset, if a subset)
  BMP non-1bpp, non-RLE
  PSD (composited view only, no extra channels, 8/16 bit-per-channel)
  GIF (*comp always reports as 4-channel)
  HDR (radiance rgbE format)
  PIC (Softimage PIC)
  PNM (PPM and PGM binary only)

With the following patches, You still need to manually add #define USE_STB_IMAGE 1 to config.h (autotools are the bane of my existence)

https://gist.github.com/technosaurus/76942ee935bdcc81d1fb

... I wasn't thinking about the case of adding more support when I wrote this; however if we just want the support for additional image formats, it should go after png and jpeg

Please don't feel any pressure to add this to mainline, I only wanted to make the patches available for embedded devs doing static builds.

@joewing joewing added the enhancement label Nov 4, 2015

@technosaurus

This comment has been minimized.

Contributor

technosaurus commented Nov 7, 2015

I also tried my hand at using https://github.com/memononen/nanosvg instead of librsvg.
The updated image.c that I used is at https://gist.github.com/technosaurus/3603768de1f83d670546
This cuts RAM usage by ~80% compared to libpng+libjpeg+librsvg and its dependencies
BTW, is their a purpose to using USE_CAIRO? I ripped those out, since it is only used with rsvg.
Is it just me, or does the image caching add significant RAM overhead compared to 2.X?

@joewing

This comment has been minimized.

Owner

joewing commented Nov 7, 2015

No real reason for separating USE_CAIRO and USE_RSVG. I could imagine using it separately (no plans to do so though).
There was always image caching in JWM. I think the caching is a pretty big performance win, especially on slower systems. It's gotten more complex with the need to support render images and now bitmap icons. For me, it doesn't appear to use too much memory, but I suppose if you had lots of large icons it could. Is it causing a problem? One way to improve the situation would be to free the raw image data. That way JWM would need to re-read the image file if a new size of the icon was required (this happens at least twice in a typical setup where the icon displayed in a title bar is a different size than an icon displayed in the task bar), but would save quite a bit on memory.

@technosaurus

This comment has been minimized.

Contributor

technosaurus commented Nov 7, 2015

Most of the overhead seems like it would be the processing of the image. If you did something like use the filename and store the processed image @ /tmp/jwm/filename/wXh with bgra data only in the file, that would cut a lot out.
So all geany images would be in /tmp/jwm/geany with a different preprocessed image for each size

@joewing

This comment has been minimized.

Owner

joewing commented Nov 7, 2015

Commit 588b736 might help with the memory footprint. JWM doesn't store the image data for images loaded from files any more. Instead, it reloads the image from disk for each size that is needed. Of course, when the render extension is used, it doesn't even have to do that.

@technosaurus technosaurus changed the title from optionally use stb_image to optionally use stb_image and nanosvg Nov 24, 2015

@technosaurus

This comment has been minimized.

Contributor

technosaurus commented May 15, 2016

I just dropped a pull request to nanosvg to support independent x and y scaling (scalex and scaley instead of a single scale factor that always keeps the aspect ratio) so that it can fully replace cairo for svg images.

If anyone is still interested in this, please check out the pull request - I'd rather not have to maintain patches from upstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment