Quote
Does this mean, in your opinion, that Threads cannot be used reliably in FireMonkey Applications?  Makes it not exactly ready for prime-time!

Certainly seems like it. 

Quote
Yes, they were in those two latter libraries.  I assume I can safely ignore the warnings?

Yes you can safely ignore these warnings.

It happens sometimes, the problem is with TThread.Synchronize (TThread.Queue doesn't work at all) in FireMonkey app - the form is
not notified that the background thread finished loading the image.

Where exactly do you mean? In Imaging core AnsiString and AnsiChar are for a reason (loading from files etc.) but warnings shoudl not be generated by Delphi. There are some warnings in JpegLib and LibTiff libraries though.

Hi,

@canvas size:
the canvas always spans the entire underlying image so the size of canvas is the same.
You can restrict canvas operations to clip rect area (by default clip rect is the whole canvas/image
so you could get canvas width and height by Canvas.ClipRect.Right and Canvas.ClipRect.Bottom).

@fading effect:
you mean like gradient fade? If yes then merging the images would probably be faster than painting the gradient
itself. You would have background image and alpha blend a prepared image with some fading effect onto it.

@blend vs alpha:
DrawBlend is general function with custom blending parameters for source and destination pixels.
DrawAlpha and DrawAdd are just DrawBlend with specific parameters set to get the desired effect.
You can experiment with blendign parameters and see what you'll get :)

Quote from: jsj on 20 May 2012, 18:38:49
PS: I can't register at this forum - get error

Please try again now.

Check out this thread about watermarks: http://galfar.vevb.net/imaging/smf/index.php/topic,304.msg819.html

Could you please check if TIFFs with JPEG compression are working with TiffLib compiled for MacOS?

dglOpenGL is still being updated so new OpenGL features are in (e.g. OpenGL 3/4),
I'm not sure if "GL, GLext" headers are. 
It doesn't matter if your game targets older hardware (where new OpenGL features are not supported
by HW anyway).

You can configure ImagingOpenGL to use "Gl, Glu" instead of "dglOpenGL headers if that's what you are using in Mundo.

New release 0.78 just needs two more bug fixes to be finished and it will be ready
for final testing. There's also quite a lot of documentation to be updated.

Hi Rodrigo,
could you provide some details about compiler and OS you use for Mundo?
Maybe there could be some problem with code in "initialization" section in Imaging in your OS+compiler combination.

Hi, that's what I'm planning now. Stay tuned just a little bit longer please :)

Thanks for the report, fixed.

Bug was found and fixed. GTK2 uses different RB order than Win/Qt/Carbon widget sets and it
wasn't checked when converting from LCL bitmap back to Imaging. I'll update repository tomorrow.

Basically, LCL/VCL stuff was added to get ability to simply display Imaging's internal image formats
in GUI apps. If you just want to load/rotate/scale/save there's no need to use LCL stuff.

Btw, ifA32R32G32B32F seems like an overkill (128bits per pixel) that the file formats you use
for saving just convert back to 24/32bit.

Look's like it is GTK2 interface or LCL RawImage related issue when converting
from LCL bitmap back to Imaging's image.
Just installed x64 Linux and started debugging...

Btw: Are you using classes from ImagingComponents unit just for saving?

TIFF tags writer was update long ago,
but it probably won't work in MS Doc Imaging
anyway due to the bug in MS Doc described previously.