Editor for convolutions filters

[Grincheux]

Thank You for your comments.
I am pleased. 

[Grincheux]

After the Pelle's comment, I have the following question.

In your post you speak about signed/unsigned variables.

3) I just looked briefly at Convolve(), and not sure how much it matters in practice (without changing code and measuring time), but more variables could be "unsigned" and some conditions inside the loops seems to apply to the whole image, so perhaps use the condition to choose between two different (tighter) loops. This will complicate the code, but if you really want those last percent of performance, it may be worth investigating... (or not).

I know what that means but in terms of performance what do I win changing signed by unsigned? I don't understand.

The only 128 bits instruction I use is when computing the histogram for setting a table to 0.

[Pelle]

I know what that means but in terms of performance what do I win changing signed by unsigned? I don't understand.

For example in address calculations, when you use 'int' (32 bits) as an index in a 64-bit (array) address. By default the index needs to be sign-extended to 64 bits (movsxd) so it can be added to the address base. This is normally a little slower than zero-extending, or not extending at all. The compiler will try to minimize the use of movsxd, but depending on the code it may not always be possible. The only reason I mentioned this is because we are talking about images. Even a small picture like 100x100 pixels means 10000 pixels to process, so small things may matter. At least in the past sign-extending vs zero-extending mattered, but modern processors are smarter so maybe less so today. Only way to know fore sure is to measure it.

The only 128 bits instruction I use is when computing the histogram for setting a table to 0.

OK.

[Grincheux]

I am sad, very sad.
All the Pelle's change have been done and I must say it is finished.
Play with the program and have as much fun as I had writing it and playing with it too.

[Grincheux]

I have some changes to win more speed.
I have made a test with the profiler and the result is very good.
Last time I made de test I had 9.3% in the "Inclusive" column.
I suppose the program is faster.

I replaced memcpy by __movsq
Made change into loops that use the edit fields
Removed some parameters in some functions
Replaced call to lstrlen with a loop.
I replaced the comparison function in C with one in asembler.

For being a "Pro", I would have to subclass the edit fields or to use the message when a field is left: WM_KILLFOCUS.
In the same style I would have to display a dialog box when an operation is time consuming, a modeless (modless?) box.

I have made a test with cppcheck, but I did not understand. Not very clear.
That is the reason I wrote the "Memory Leaks" module.

[John Z]

Living up to your motto!

For long running ops I've used a DialogBox in a thread asking the user to wait but also allowing them to terminate the long running process gracefully if they decide not to wait....

John Z

[Grincheux]

I didn't get very tired. On this site, I found the work already done by Raymond Chen.
I have added a wait dialog box, in fact the suggest you to have a coffee!

Source code
Binaries