|
I've got a PNG with alpha-channel, but it doesn't show transparently. What's wrong?
|
|
The TNGImage component doesn't work with a 'transparent' property nor its containers (eg. TImage) 'transparent' property. You'll need to set the 'BGColor' and/or 'BGImage' property of the TNGImage component before its canvas is getting filled. Eg. either before the LoadFromFile/LoadFromStream procedure or during the OnProcessHeader event.
|
|
|
I've set the BGImage property with my background bitmap, but I get an access violation. Help!
|
|
The underlying libmng library expects the background-image to be of the same size as the image/animation it is displaying. And TNGImage isn't smart enough (yet?) to adjust the BGImage. So you'll need to do this yourself. If you know the PNG/JNG/MNG's dimensions beforehand that's easy enough. Otherwise, you'll have to write an OnProcessHeader event-handler that queries the TNGImage for the dimensions found in the header-part of the PNG/JNG/MNG, adjust your background-bitmap accordingly and just then set the 'BGImage' property with it.
|
|
|
Why does this work with a DLL?
|
|
The libmng library is open-source and written in platform-independant C. It would be possible to compile it into a binary object that gets wrapped inside Delphi, but to allow users to work with the very latest library I felt it best to work with a separate DLL. The advantage is that it's transparent and gets loaded only when needed, saving internal memory consumption, which is high enough as it is for most apps.
|
|
|
The DLL is around 200KB. Earlier versions where at least 400KB or more. Did you cut something out?
|
|
Nope. I've just used the excellent ASPack utility to compress the binary. See www.aspack.com for more info.
|
|
|
How does the dynamic loading work?
|
Basically as soon as you create a TNGImage component, either explicitely or implicitely (eg. loaded at design-time when using packages), the libmng.dll gets loaded automagically. This is done in the constructor. It's simply a reference counter that gets increased. It gets decreased in the destructor, and if it reaches zero the DLL is unloaded again.
If you don't like this behavior, you can call the BeginUseLibmng procedure (or BeginUseZlib if you're only using the zlib functions) in the NGTypes unit. This will put the ref-counter at 1, and unless you call EndUseLibmng yourself again, it will never reach 0. Eg. the DLL gets loaded and stays loaded.
Note that on modern systems there's hardly a performance penalty loading the DLL. Anything with a 200MHz CPU or faster probably won't have to wait more than 1/10th of a second. Of course if you're creating and destroying TNGImage components in some kind of batch-fashion (perhaps an ani-GIF -> MNG conversion app), you'll want the DLL to stay loaded.
|
|
|
Can I turn the dynamic loading off alltogether?
|
|
Yes. Change the setting in the NGDefs.inc file.
|
|
|
Does the TJPEGImage replace the one that comes with Delphi?
|
|
Yep. Just replace the 'JPEG' unit in your 'uses' clause by 'NGJPEG' and everything should work as before, except that your executable is a fair bit lighter!
|
|
|
How can I create a MNG with delta-images?
|
|
There's no or little support for this at the moment. The underlying libmng library can be used to create a MNG and write it to an output-stream, but you'll need to have a fairly detailed understanding of the MNG format as you'll be constructing the so-called chunks mostly by hand. Creating delta-images will require additional work as you'll need to 'subtract' subsequent images from each other to get the actual delta-image and then construct the IDAT's to be sandwiched between the DHDR and IEND chunks. All in all it's almost enough for another library, so there's not a lot of change it'll make it into libmng or TNGImage at any time soon...
|
|
