mapPixel() is very slow

[Jan]

Hi
I tried to implement a shader with the mapPixel() function.
Each time before drawing a picture, I apply a function which change the brightness of a pixel acording to the mouse position. That worked out so far.
But crux about this, this simple function drops my FPS to 2!!
Does anyone know a way how to implement such a thing more efficient?

Jan

[TechnoCat]

I believe this is a CPU and GPU communication bottleneck.

You might have better luck with more hackish shader methods. Create a black image that follows the cursor with a transparent hole in the center.

[T-Bone]

I'm not sure about all the stuff you're doing in this example, as I'm new to LÖVE myself. However, I can't help but to note something in your love.update(dt). You do love.graphics.newImage() twice. I used to be and Android programmer, and from that I learnt one thing: Never, ever, create new objects every frame. This will cause the garbage collector to be drowned in objects to remove. I'm not sure how fast the garbage collector in lua/LÖVE is though, so this may not be the reason you program is slow. Just wanted to point that out. There is probably a better solution.

[bartbes]

Time to calculate how much loops an 800x600 image does.. 240000.. hmm.. I wonder if that could slow it down.. .

[T-Bone]

I'm guessing mapPixel() can still be useful, even on larger areas, if you edit an image like once, or only every once in a while, and then reuse the old one all the other frames. In TC:s example, you could probably improve performance a lot by only creating a new image when the mouse is actually moved.

Still,TC:s approach is very bad. A better solution, as already been suggested, is to draw two images on top of eachother, one being semitransparent.

[tentus]

I'm guessing mapPixel() can still be useful, even on larger areas, if you edit an image like once, or only every once in a while, and then reuse the old one all the other frames. In TC:s example, you could probably improve performance a lot by only creating a new image when the mouse is actually moved.

Still,TC:s approach is very bad. A better solution, as already been suggested, is to draw two images on top of eachother, one being semitransparent.

What? TechnoCat's solution is the fastest, most efficient one I can think of. Make a big PNG ahead of time to cover the screen. It doesn't have to be altered at all except when the mouse moves, and even then it is only to change the XY coords.

[nevon]

I'm guessing mapPixel() can still be useful, even on larger areas, if you edit an image like once, or only every once in a while, and then reuse the old one all the other frames. In TC:s example, you could probably improve performance a lot by only creating a new image when the mouse is actually moved.

Still,TC:s approach is very bad. A better solution, as already been suggested, is to draw two images on top of eachother, one being semitransparent.

What? TechnoCat's solution is the fastest, most efficient one I can think of. Make a big PNG ahead of time to cover the screen. It doesn't have to be altered at all except when the mouse moves, and even then it is only to change the XY coords.

I think he meant Topic Creator, not TechnoCat.

[TechnoCat]

I think he meant Topic Creator, not TechnoCat.

Aha! That was throwing me off quite a bit too. I was only aware of OP.

[T-Bone]

I'm guessing mapPixel() can still be useful, even on larger areas, if you edit an image like once, or only every once in a while, and then reuse the old one all the other frames. In TC:s example, you could probably improve performance a lot by only creating a new image when the mouse is actually moved.

Still,TC:s approach is very bad. A better solution, as already been suggested, is to draw two images on top of eachother, one being semitransparent.

What? TechnoCat's solution is the fastest, most efficient one I can think of. Make a big PNG ahead of time to cover the screen. It doesn't have to be altered at all except when the mouse moves, and even then it is only to change the XY coords.

I think he meant Topic Creator, not TechnoCat.

Yes, indeed. I didn't think about the fact that TC could be short for TechnoCat, sorry

[Robin]

Yes, indeed. I didn't think about the fact that TC could be short for TechnoCat, sorry

And that's why one should never use abbreviations, IMHO.