Hi guys, I am trying to implement a real time box blur filter on a 640 x 480 screen. My strategy is doing 2 separate 1D blurs, blur pixels in horizontal direction in the first pass, then blur vertically in the second pass. So we effectively end up using a cross shaped kernel instead of the square shape (hence less pixels to be processed over all).

Below is my code, it works fine, result looks great, but i wonder if you guys can suggest anything which could further speed up the algorithm?

publicclassBlurFilter {//Blur filter set the value of each pixel to the average value of its neighboring pixels.//the filter kernel used here has a cross shape instead of square, the size of the kernel depends on radius.publicstaticvoidfilterPixels(intradius, int[] img, int[] offsSreenBuffer){

Use ++i not i++. In c++ world this have small performance difference. Don't know about java.

PROVE IT.

Didn't I just see this claim made in another post?

Maybe I should not belive my professor so naively. But its common belive and there is lot of fun stuff at google about that. I triead to test that with nanotimer but results was too wide margin to get anything statistically significant.

If ++i is faster than i++ in this context it is because you have a crap compiler or you forgot to use your -O3 switch (or even just plain -O). This is what is called a peephole optimization, like changing i=i*2 to i=i<<1, its very easy to and cost no compile time.

The only time i think it could possibly make a difference is if you use the post increment/pre increment behavior somehow. Say like this:

1 2 3

if(++i<x++){System.out.println("I am freaking awesome");}

To which I say, Yuck!

I have no special talents. I am only passionately curious.--Albert Einstein

Use ++i not i++. In c++ world this have small performance difference. Don't know about java.

PROVE IT.

Didn't I just see this claim made in another post?

Maybe I should not belive my professor so naively. But its common belive and there is lot of fun stuff at google about that. I triead to test that with nanotimer but results was too wide margin to get anything statistically significant.

Pre-increment may be faster in C++ when applied to objects. This most commonly occurs with iterators where you do ++iterator at the end of a loop. With the post-increment there's a temporary object created and discarded, but not with the pre-increment. Of course stupid people like your professor probably just start parroting 'pre increment is faster' without understanding that.

Of course with a good optimising compiler the temporary may even be optimised out, but IMHO it's not good style to rely on that.

The C standard says the precise behavior of mixing preincrement and postincrement is undefined. Now in a sane world, that just means the precise ordering can't be relied upon: one implementation might post-increment x after preincrement, another might end up incrementing only the unincremented x, making the post-increment a no-op. But there are some more exotic interpretations of "undefined behavior" out there, such as the Jargon File's "causes demons to fly out of your nose" tradition: http://catb.org/jargon/html/N/nasal-demons.html

I'm not actually sure whether Java also left it undefined, though the JLS tends to preclude such things as nasal demons.

The C standard says the precise behavior of mixing preincrement and postincrement is undefined. Now in a sane world, that just means the precise ordering can't be relied upon: one implementation might post-increment x after preincrement, another might end up incrementing only the unincremented x, making the post-increment a no-op. But there are some more exotic interpretations of "undefined behavior" out there, such as the Jargon File's "causes demons to fly out of your nose" tradition: http://catb.org/jargon/html/N/nasal-demons.html

I'm not actually sure whether Java also left it undefined, though the JLS tends to preclude such things as nasal demons.

Are you sure you're not confusing this with modifying multiple times without a sequence point? The code snippit is incrementing two separate variables, which I think should be ok. Now if they were both operating on the same variable I think you'd be right.

Yeah , I did have a look at the link above , but most of my code was inspired from Jerry's image processing page (http://www.jhlabs.com/ip/). I found Jerry's page easier to follow up thanks to the live applet demo he put up there.

My suggestion would be to look at Romain's code as it might be easiest to follow. Go to the Filthy Rich Clients webpage -> Examples -> Chapter 16. Static Effects, and look for FastBlur. Bloody site uses JavaScript which means deep linking isn't easy! Angry

Best wishes, Neil

I have read through the code of "Romain Guy", as you said it is quite easy to follow. I was able to replace all my "/" operations by lookup tables and got 3fps boost in performance Really nice trick indeed.

it's incredibly asinine to argue about its speed though (like, it does NOT matter at all whatsoever), but it definitely feels better to know when to utilize the proper increment operators at any given time

I think you mean ==. I'm open minded, if you want to be a large bundle of sticks then go you.

== isn't a declaration operator, just an equality one

Aye, but you've changed your example from what it was when Roquen read it, and what you have now wouldn't even compile (a++ and ++a are invalid lvalues). His point was that in your original post, you probably meant something more like this:

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org