search

joewing / jwm

Joe's Window Manager
http://joewing.net/projects/jwm
MIT License
510 stars 83 forks source link

optionally use stb_image and nanosvg #242

Open technosaurus opened 8 years ago

technosaurus commented 8 years ago

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.

technosaurus commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

Commit 588b7366ef9dc355dfb0297ea3e88bbd88695852 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 commented 8 years ago

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.