Adding JPEG to PictureFlow

[zajacattack]

For PictureFlow, would it be possible to simply include apps/plugins/jpeg.c in it and then add JPEG in from there?

[Llorean]

What would be the point, JPEG images still won't work for the WPS and would just cause more complaints because "Album Art works in pictureflow but not my WPS". One of the points of pictureflow is to work the same as what the WPS supports.

[zajacattack]

OK, so it is preferred to add JPEG to the core and WPS, then to pictureflow, right?

[saratoga]

Yes, in the long term decoding/resizing/etc should probably all be handled by the core on targets with sufficient ram to spare in order to avoid duplicating code across all the different parts of rockbox that need those items.

[Llorean]

There's a group that strongly feels jpeg in the core is unnecessary.

[zajacattack]

Well, what would be the pros and cons of it? Why would anyone be against it?
EDIT:
Is there resistance to PNG in the core as well?

[Llorean]

Because it uses additional ram and adds unnecessary complexity? It's the same reason why hundreds of "Well, why can't you also do this" features get rejected. Rockbox doesn't need to do _everything_ and generally speaking you can spare more disk space than you can CPU time and RAM. That's not to say JPEG won't be implemented, just that "it's more convenient" is really the only argument for it, and "it hurts people who don't use it, even if it's a fairly small amount" is the argument against it.

[zajacattack]

So, it would take RAM even if it was only used for album art?

[linuxstb]

There are also core devs who feel that Rockbox should be able to play any file a user throws on their DAP, and as Rockbox supports album-art, we should support the most common way album art is stored - as embedded JPEG...

But this argument is pointless until someone actually writes a patch to do it.

[Llorean]

Any time you make the Rockbox core code larger, it uses more RAM, yes.

And yeah, "most common formats" is a good argument in favour of it.