Image fade and floodfill library

agraham

Expert
Licensed User
Longtime User
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.
 

Attachments

  • FillFade1.1.zip
    39.7 KB · Views: 152
Last edited:

RandomCoder

Well-Known Member
Licensed User
Longtime User

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

Expert
Licensed User
Longtime User
RandomCoder said:
And yet you seem to have become somewhat of an artist
Click to expand...
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

Well-Known Member
Licensed User
Longtime User
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

Well-Known Member
Licensed User
Longtime User
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

Expert
Licensed User
Longtime User
alfcen said:
Actually, fading two images on an Image
control is yet faster than fading on a form
Click to expand...
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.
Click to expand...
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
B4X: 
 *pixel3++ = (byte)((*pixel1++ * oldpercent + *pixel2++ * newpercent) / 100);
and I can't get it any simpler than that
 

alfcen

Well-Known Member
Licensed User
Longtime User
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
 
M

mjcoon

Well-Known Member
Licensed User

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

Expert
Licensed User
Longtime User
mjcoon said:
Could this be implicated in this case?
Click to expand...
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.
 
M

mjcoon

Well-Known Member
Licensed User
Thanks Andrew, that comprehensive and comprehensible answer also sounds very efficient!

Cheers, Mike.
 

agraham

Expert
Licensed User
Longtime User
sounds very efficient!
Click to expand...
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!
 
You must log in or register to reply here.
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…