Image fade and floodfill library

[agraham]

I have knocked up an image fading function for Alfcen (Robert) and included it with my floodfill routine in this small library. No help as its' fairly obvious from the sample app but if you ask for one I'll write one sometime.

For device and desktop but needs .NET 2.0 to provide the image manipulation operations.

 

[RandomCoder]

No - only when explicitly passed as a parameter to a library call.

This is a property of the object being drawn on, not of the language. I'm not a graphics person and don't know how this works. I also don't know how the forelayer works in B4PPC. The form background is available to a library by the form image property - whether that image also contains the merged forelayer I don't know. I'd draw on a bitmap from the imagelib library displayed in an image control using only setpixel and getpixel. That gives you a chance to later do the same things with the same logic but as low level pixel work in a library.


P.S. Don't think that I will necessarily write a library for you. As I said above I don't enjoy graphics work and have other things I am doing.

Remember this??
And yet you seem to have become somewhat of an artist

I hope that one day I have the abillity you've got to write whatever code takes your fancy :sign0188:

Regards,
RandomCoder

 

[agraham]

And yet you seem to have become somewhat of an artist

Thanks for the compliment but not really. I distinguish imaging (as in manipulating photos. etc.) from graphics (as in designing and drawing original work). I've been interested in colour imaging on computers for years but totally lack the design flair and imagination to make graphics a worthwhile excercise.

 

[alfcen]

Hi Andrew,
For me??? That's fantastic!
Indeed, no help required, your sample is great.
Thanks so much, I will try it tomorrow in my slide show app
and let you know :sign0060:

 

[alfcen]

Hi Andrew,
Here is my feedback.
Everything works fine on the desktop. On the device, the transitions
are too slow. Say, a slide show runs in intervals of 5 seconds, while a
transition takes longer than that, the show ends up in a plausible
"out of memory exception". Actually, fading two images on an Image
control is yet faster than fading on a form.

The images to fade are stored in an ImageList:
Fader1.NewFade(il.Item(0),il.Item(1), cBlack, true)
Timer interval 20ms, Faded = Faded + 5 transition steps.
Image sizes are 640 x 480px.
The device, an iPAQ h2210, runs Pocket PC 2003.

Your demo with the much smaller images performs acceptably smooth.

Anyway, a fantastic approach, Andrew. I will experiment further
and eventually find a compromise for the device.

Keep it going :sign0098:

Cheers
Robert

 

[agraham]

Actually, fading two images on an Image
control is yet faster than fading on a form

I'd sort of expect that as a Form does extra things when assigned a bitmap in order to be able to redraw it.

Image sizes are 640 x 480px.
The device, an iPAQ h2210, runs Pocket PC 2003.

Doing fast graphics on a screen that size is a bit ambitious for the processing power of a PPC. Unfortunately I can't speed it up any more and still write in C# as I've optimised it as much as I can. The code that does the work looks like

 *pixel3++ = (byte)((*pixel1++ * oldpercent + *pixel2++ * newpercent) / 100);

and I can't get it any simpler than that

 

[alfcen]

Hi Andrew,

Perfectly agreed, processing several steps in an array of 307,200 pixels
in a matter of a second or so is a job for pure C programs.
Your solution is fabulous for the desktop and smaller images in the device!
I will shrink the images to QVGA. They will look fine on a VGA device screen.
Thanks so much for your hard work. I really love the library as it is. And...
you made it for me :sign0100:

Cheers
Robert

 

[mjcoon]

... The code that does the work looks like

 *pixel3++ = (byte)((*pixel1++ * oldpercent + *pixel2++ * newpercent) / 100);

and I can't get it any simpler than that

I'm only qualified to comment having been around for a long time and worked in multiple languages... (By way of saying I'm ignorant of this compiler and of PPC processor architecture!)

But elsewhere, a complex expression like that might entail converting its terms to floating point for the calculation and back again if the assignment were to an integer. This would make it much slower than purely integer computation. Could this be implicated in this case?

Regards, Mike.

 

[agraham]

Could this be implicated in this case?

No. Slots on the CLR evaluation stack are either 4 or 8 bytes wide. Depending upon the data types of the operands arithmetic operations are performed as Int32, Int64 or Double operations. Lesser types are promoted to one of these types when copied to the stack and demoted on storage.

In this case Int32 operations are used.

 

[mjcoon]

Thanks Andrew, that comprehensive and comprehensible answer also sounds very efficient!

Cheers, Mike.

 

[agraham]

sounds very efficient!

Note that only B4ppc libraries can do really efficient arithmetic. B4ppc itself is not (at the moment) particularly efficient at arithmetic. As a weakly typed language numbers are stored as strings and converted to Doubles (64 bit floating point) for arithmetic and then converted back to strings for storage. Even using typed arrays (the only place types are currently recognised by B4ppc) and the optimising compiler numbers are still converted to Doubles for arithmetic and then converted back to their declared type. This places a prticular inefficiency on a device as they do not have an FPU and must do floating point in software.

Erel's has promised typed regular (non-array) local and global variables for the next major update, hopefully he will optimise the arithmetic for integer types at the same time - at least in the optimising compiler!