Using Enlightenment 17's Epeg API (Part Deux)

jjrff writes "The Enlightenment project has turned up some really cool bits lately. here is a nifty article about using their Epeg bits to easily deal with thumbnailing. Note that they also have a great deal of sample code for things like canvasing and even dealing with network delivery."

Comments

This would be great

[Anonymous Coward]

if anyone actually used it...

Re:This would be great

[Nova1313]

someone actually will.. I wouldn't be so surprised if you didn't see some of this code end up on gnome or kde... Enlightenment is very fast. Even if you don't like it's window management styles their graphics code is quite amazing...

Re:This would be great

[chez69]

gnome used to use imlib but moved away from it because the code was a mess and full of memory leaks.

Re:This would be great

[the_greywolf]

imlib2 is a rewrite that fixes most of the problems imlib had, and adds a lot of features and optimizations to boot.

Umm, what?

[Otter]

OK, but this offers what over existing thumbnailing functions (KDE, GNOME, ImageMagick) that have the advantage of being much more likely to already be installed on a normal user's system? I thought it might be the caching, but the example code seems to do all the caching itself.

Incidentally, as long as there is an Enlightenment topic, why not use it?

Re:Umm, what?

[tolan-b]

epeg is meant to be very fast.

Re:Umm, what?

[madaxe42]

Epeg is very, very fast. Directory of 220,000 images, all about 300x300 (website user images, before you ask) - thumbnailed the lot in under a minute.

Re:Umm, what?

[rylin]

"Website user images".
chuckle

(No, not a question. We have no NEED for questions :P)

Hello, moron alert

[Nevyn]

directory handling interfaces are all that need to be added, plus a few defines:
[...]

#define LEN 1024

[...]
the LEN value is the standard string length - this can also be grokked from the limits.h file.
[...]

static char path[LEN];

strcpy(path, dir);
strcat(path, /);
strcat(path, file);

return (path);

Hmm. So there's this limit called PATH_MAX, and instead of using it we'll just type the number in? Not to mention that nothing stops something passing strings bigger than that to your application, PATH_MAX is just the max size you can pass to open() etc. Oh, but it gets better:

% egrep PATH_MAX /usr/include/linux/limits.h
/usr/include/linux/li mits.h:#define PATH_MAX 4096 /* # chars in a path name including nul */

Muhahhahaha. It's an article written by someone with no clue, about an API that noone uses ... /. says: +8 insightful.

Re:Hello, moron alert

[LizardKing]

His reliance on static variables in functions is also yucky. Say hello to code that's never going to be thread safe. The path stuff the parent poster noted is the most breathtaking error though ...

Re:Hello, moron alert

[nickos]

Fair point, but if he knows he's not going to use that code in a thread isn't this okay - he can always change it later if he ever rewrites the code to use threads.

Isn't the use of static variables a good thing if the alternative is to use global variables. If he was using C++ he would probably encapsulate these and have a method using a private attribute, but given that he's using C isn't it okay?

Re:Hello, moron alert

[Anonymous Coward]

> Isn't the use of static variables a good thing if the alternative is to use global variables.

The alternative is normally to write code that's threadsafe, not use globals (statics are merely globals with restricted scope). In all fairness, display managers usually need only run in a thread, and don't themselves need to be threadsafe.

Raster's a pretty amazing hacker, but his code is usually riddled with leaks and exploitable overflows.

Re:Hello, moron alert

[nickos]

Ah, I just looked at the code. That's quite pointless actually isn't it?

Re:Hello, moron alert

[jvalenzu]

snprintf(path, n, "%s/%s", dir, file);

Re:Hello, moron alert

[raster]

aaah this explains the gartuitously slow code on todays machines. people thinking snprintf is better than strcpy/strcat.

snprintf method takes: 0.571 sec for 1,000,000 iterations, strcpy etc. 0.124 sec. you have to think that every time you do something you choose a method 4+ times slower that no wonder today's software is not appreciably faster on machines 100+ times faster that they were 10 years ago.

code for the test:
#include
#include

int main(int argc, char **argv)
{
      int i;
      char buf[1024];
      char *s1 = "/path/to/whatever/here/to/test";
      char *s2 = "a_file_name_goes_here.blah";

      for (i = 0; i 1000000; i++)
          {
#if 0
                snprintf(buf, sizeof(buf), "%s/%s", s1, s2);
#else
                strcpy(buf, s1);
                strcat(buf, "/");
                strcat(buf, s2);
#endif
          }
}

you can figure it out :)

Re:Hello, moron alert

[KainX]

You'll use any excuse you possibly can to advertise vstr, won't you James? Kindly get over yourself and realize that the point of the article was not to create the perfect program.

It's an example, for fuck's sake, not a thesis. Move on.

Re:Hello, moron alert

[Anonymous Coward]

Ah geez...worthless /. zealots. Maybe before you declare someone a moron, you should RTFA. From the bottom of the article:

There are, some obvious, changes that should be incorporated into this program, as was noted earlier, there are intentional flaws, the next article will address them:
* System header files are not used to their fullest (hint, see include files).
* Safer string manipulation?
* Absolute paths might be safer.
* There should not be any globals.
* Command line arguments for epeg settings, src directory, and dst directory.
* Using more of the Epeg API (for instance, comments).
* Anything else . . .

Obviosly, this code is just some example code that was whipped up in a jiffy. He even mentions that some of the flaws are _intentional_! This is _not_ finished code. Please RTFA, moron.

Re:Hello, moron alert

[jvalenzu]

Well that explains the glacial progress of enlightenment. Why don't you optimize the idle loop, the system spends a lot more time there.

Re:Hello, moron alert

[raster]

Oh the lack of clue on actual facts is astounding... oh waity. i forget. This is slashdot.

Re:Hello, moron alert

[predakanga]

Really? I would have chosen him typecasting the return value of closedir, when he's not going to store it (and casting it to void, no less) - I've checked and this doesn't even generate a warning in GCC when compiling with -Wall

Enlightenment has always been Enlightening :)

[Gopal.V]

Rasterman is the crazy scientist of desktop programming. He does all kinds of innovative shit, most of which push the boundaries of normal programming, but doesn't give you much other than a view of the possibilities.Stuff he does using the CPU is magic, I've seen enlightenment just rock on a P III 450 - and with just X11 , no OpenGL - no GPU at all.

But, he often doesn't make something you could install on a corporate desktop (I use fluxbox at work). The last E17 install I had has flashing titlebars but Alt+Tab doesn't work. So I hope more and more people learn from E17 and push the envelope for the ordinary user.

Re:Enlightenment has always been Enlightening :)

[the_greywolf]

alt+tab works now and has a nifty little window list that pops up.

kinda spiffy how it works, too: as you alt+tab through the windows on the current desktop, the mouse cursor moves to the center of each window, as it brings it to the front.

Re:Enlightenment has always been Enlightening :)

[yoder]

I've been using e16 on a couple of Ubuntu machines and I like it. I've also looked at e17 on this
Debian Live cd and it is impressive. I initially thought it would be distracting to work with it, but once I got my desktops configured it turned out to be more efficient to work with than KDE (which is still my primary).

Re:Enlightenment has always been Enlightening :)

[Anonymous Coward]

you suck, now i'm going to have to go get a newer version of enlightenment from cvs and recompile it in order to get my alt+tab working... thanks a lot...

Re:Enlightenment has always been Enlightening :)

[CaptnMArk]

Mouse pointer moves?

This reinforces the parent post.

Moving the user's mouse pointer is bad for usability.

Re:Enlightenment has always been Enlightening :)

[Anonymous Coward]

>Moving the user's mouse pointer is bad for usability. why? just because you, you don't like it ?

Re:Enlightenment has always been Enlightening :)

[CRCulver]

Moving the user's mouse pointer is bad for usability.

Not when E17 uses a focus-follows-mouse system by default. Then it is necessary that the mouse pointer move, and users will expect that.

Epeg

[Rabid Penguin]

Hold your breath for I shall perform a feat rarely seen on Slashdot... I will actually talk about the subject of the article!

Epeg has one purpose, to scale JPEG images very quickly. One of the primary reasons it was created was because of the freedesktop.org thumbnail spec. The spec requires that the thumbnails be stored as PNG's. While experimenting with this, it was found that converting large JPEG's to PNG's was a relatively slow process because of the color space conversions and IDCT. If the spec was extended to allow JPEG thumbnails, then the conversion process can be JPEG to JPEG.

By keeping the formats the same, you can now do the scaling during the jpeg decode (avoid extra pixel traversals scaling the RGB data after it has been decoded), keep JPEG native color space (no YCbCr->RGB conversion, again traversing the pixel data, twice if you go back to non-RGB image data), and reducing the output written to disk in almost every case (because of the end result being a JPEG rather than a PNG).

Overall, it exists because it didn't seem right to not support the most common image format as a thumbnail when it allows for such large speed increases creating the thumbnails and reduced disk space used for meta-data. Just because disks get larger and CPU speeds increase doesn't mean we shouldn't use them wisely, especially when it's less than a days worth of hacking to do so.

RFA

[Anonymous Coward]

You wrote:

So there's this limit called PATH_MAX, and instead of using it we'll just type the number in?

and the article has:

Of course, the directory names are defined, the LEN value is not a standard string length - this can also be grokked from the limits.h file.

And of course you wrote:

% egrep PATH_MAX /usr/include/linux/limits.h

Hmmm. Do you think the author of the article knows about limits.h but doesn't want to get bogged down in details?