Re: [dev] Lightweight, non-bloated, fast image viewer?

From: FRIGN <>
Date: Sat, 14 Jun 2014 14:52:39 +0200

On Sat, 14 Jun 2014 12:42:00 +0200
Markus Wichmann <> wrote:

> So, having one program that reads some standardized input and displays
> it on screen, while another program converts any given image file to
> that standardized format may be more UNIX-like. But maybe a file is not
> the right representation for that standardized format. So maybe the
> converter would need to be a library instead of a program.

This is a very nice idea. What any image-lib basically does for
internal representation is to load the image as a bitmap.
An image-viewer for bitmaps piped by a converter for the common formats
would be a good idea.

> So yes, I argue we should rather rewrite imlib, that is, try to
> implement imlib's interface in a suckless way. Unless that is
> impossible, then the "rewrite feh" idea is the only one left.

imlib2 is more than reading images, it's also a full-fledges
font-rendering-engine and image-compositor.

I'd look at it this way: Do we really need this much stuff for a simple
image viewer? Wouldn't it be better to just take the stuff we need
(reading images and mapping it to a certain common standard format) and
be fine with it? ;)

Concerning the second question, we wouldn't be far away from what I
already gave as an example. Loading png's, jpg's or raws by first
loading it as a common format still involves their standard libraries.

However, with the difference, that this loading-procedure would
simplify things on the graphics-end.



Received on Sat Jun 14 2014 - 14:52:39 CEST

This archive was generated by hypermail 2.3.0 : Sat Jun 14 2014 - 15:00:08 CEST