Can Haiku use patched libpng with APNG support?
I know, software giants doing anything to destroy APNG in favor of their own (MPEG-LA’s, WebP etc.) by refusing it, but maybe Haiku can provide support for it?
Nice to see working animated transparent image format with full backward compatibility to PNG, maybe it’ll found his own place inside system and apps.
https://sourceforge.net/projects/libpng-apng/ — patch
http://littlesvr.ca/apng/gif_apng_webp.html — comparison between GIF, WebP and APNG (Firefox or Safari needed to see APNG animation).
Support in libpng wouldn’t bring much to us. In Haiku, there is currently no support for animated images. ShowImage handles only still images (even for GIF).
We could display them in MediaPlayer if there was a decoder plug-in.
It is not a problem to write a recipe and make a package for the modified libpng.
Inside the system and apps, however, we are pushing for vector graphics whenever possible (HVIF icons, but also all drawing operations in apps). So, I would rather like support for animated SVG, if we wanted to support an existing format. But, if the lib is there in the packages, I don’t see why an app couldn’t use it.
1 Like
Do not see any problems to have both formats.
So I’m understanding correct that I can’t just patch libpng but also need to do complex changes inside graphics layer?
I’m not sure what you want to do.
I don’t know what you mean by the “graphics layer”.
To show an image on the screen on Haiku, the usual way would be:
- Application asks the translator kit to load a file or data payload
- The translator kit asks all translators to try to decode the file
- One of them (in this case, the PNG translator) sees a file it can handle, so it is selected
- The translator uses libpng to decode the file and get the raw data from it
- The data is converted to another format suitable for the app. In most cases, it is converted into a BBitmap.
- The app draws the bitmap on screen (or does whatever it wants with it)
A BBitmap represents a single picture. It is not suitable for animations, multi-page PDFs, etc. The translation kit itself is generic, but there has to be a common format to convert to. For animated pictures, at the moment there is no such thing. And even if there was, it wouldn’t mean there is a way for applications to render it.
If you want to show animations, a better choice may be to look at the media kit instead. It has its own way to read data from files, because the translation kit was not suitable for streaming media (it would uncompress a whole video to memory, not the best thing to do if you want to play a DVD for example). It turns out, ffmpeg has built-in APNG support since version 2.5. So, a gcc5-compiled application could give an APNG file to the media kit and it would be decoded just fine. Then it would be used as with any video file. We could for example allow MediaPlayer to play APNG files on gcc5 system (not gcc2hybrid which uses a much older version of ffmpeg, unless someone backported the decoder to it).
1 Like
Sorry for oftop, why gcc5hybrid is not default build?
Offtopx2: do we (I mean users) need to move from gcc2h to gcc5h builds? Which branch must be the main?
We decided to provide 2 officially supported platforms:
- x86_64, for modern setups where legacy compatibility doesn’t matter,
- gcc2hybrid, for places where maximal compatibility with BeOS is required (including drivers, add-ons, etc).
It is not easily possible to support BeOS drivers and add-ons (translators, screensavers, media plugins, …) in a gcc5hybrid. If you don’t care about the legacy of BeOS, which is fine, then just use the 64 bit version. This way we can keep focused on only 2 supported platforms, and provide solutions to our complete user base, from people who need max compatibility, to those who want nice and modern things. The gcc5hybrid does not cover much additional users: those stuck with old 32bit hardware but not caring about BeOS - they can run the gcc2hybrid until they upgrade to a 64bit machine.
1 Like
I have x64 machine with 4GB of RAM (Xeon X5460 based), but I’m using x86 Haiku.
x64 needed only for special tasks (and for 4+GB RAM on Windows due to lack of PAE),
but I see Haiku as simple, user-friendly and memory-effective home system.
I remembered when x64 appears on market they said that even x86-32 code can work faster by performing more x86-32 commands, but that’s a lie.
So, x64 on my machine is only for Windows, 'cause 4GB RAM and some specific apps are x64 only.
Even on my tablet I have x86 Windows and there’s no problems.
I don’t need x64 version of Haiku, do you? What a purpose for x64 here? Please explain, I don’t understand.
When we ship Haiku for x86, we have to make sure that it works:
- On machines with and without PAE support
- On machines with and without SSE2 instructions
- On old machines with broken ACPI tables
- On old machines with only USB1 ports, IDE disk drives, AGP video cards, etc.
In general the 32 bit x86 PC is full of legacy stuff and strange things to get things running.
When we ship Haiku for 64-bit, we can assume support for more than 4GB of RAM, working SSE2 and more new instructions, reasonably good ACPI tables, USB2, SATA, etc. It allows us to remove a lot of old code and workarounds. The instruction set is also cleaned up and a bit simpler to manage. In 32-bit Haiku, we have to maintain more drivers, check wether CPU instructions are available before using them, and generally do a lot of tricks to get things running.
The limitation to 2GB of RAM per application (not 4GB in Haiku, because we reserve half the memory space for kernel-side things) is also sometimes getting in the way. For example, it is not possible to run WebKit testsuite completely, one or two pages try to use more than 2GB of RAM so we have to skip these tests (they are very complex pages, of course, not something you would find in real life).
That being said, the gcc2-hybrid is there if you don’t care about all this and want to stay with it. And the gcc5hybrid is also there, even if there is no plans for official support for it.
2 Likes
Thank you, that’s a complete answer.
Is there are plans for x86_64_hybrid (64 bit Haiku + 32 bit layer for BeOS apps)?
That would be nice, but there is need for extra development work. For this to work, a translation layer has to be added to convert 32 bit pointers from an application to 64 bit ones for the kernel, in all system calls.
We don’t have anything started on that front yet, but it would be the best long term solution.
Slightly off topic but slight;y related topic is support for PNG 32-bit bitmaps with Alpha channel. As I understand it, Haiku will read PNG 32-bit bitmaps with Alpha channel, but will not render the Alpha channel.
It would be a great benefit to many graphics and video apps. Alpha channels support transparency and overlays. This is very powerful for Photoshop effects and video effects. It is also useful for game development.
So perhaps someone can read this and become inspired to add Alpha channel rendering support and a few simple app examples.
Alpha channel in PNG should work just fine. Just use the RGBA32 color space when creating your BBitmap, and use B_OP_ALPHA when rendering it to a BView. No problem with that whatsoever.