ReadPixel WritePixel speed

[Hardcoal]

Hi, Im using Xors3D and I use Writepixel and readpixel commands.
the writepixel is much slower than readpixel.. in xors3d
is it the same in blitzmax read write pixel?

also is there anything that can be done to make it faster?

Cheers

[Hardcoal]

I guess no one has a clue

[TomToad]

ReadPixel and WritePixel commands themselves are actually quite fast.  The problem comes when you need to display the imgae.  The image is modified in the CPU's memory, so must be transfered over the bus to the GPU's memory before it can be displayed.  This actually takes time.  That is why it takes so much longer to write to an image than read from it.

[Hardcoal]

But when im writing pixel i dont display it..
so i dont understand why its slow

[Matty]

How many pixels are you writing?

A full screen or a handful?

How many functions, calculations are you doing per pixel?

Are you performing any slow operations per pixel such as square roots or trig functions?

Are you calculating rgb values with a function call or a calculation?

[Hardcoal]

I do no function calculation on the pixel i just read a pixel from one image and and write on another and it can start from 1000 and get to million approx..

[Matty]

Well if there are no calculations or processing why not use a copyrect method instead of pixel writing and reading?

[Hardcoal]

because i need to read pixel by pixel for what im doing..
but thanks for the suggestion here is what  im working on https://1drv.ms/u/s!ArSvOuhm7L3ko51b1gpP7GPIeBy8bw?e=HXdnj7

[Matty]

Okay.  Here is another suggestion.

Do all your readpixels in one set.

Then all the writepixels.

In otherwords dont alternate between reading 1 pixel then writing 1 pixel.

Do them all at once.

Also if you can do multithreading then read each channel r g b and a in a thread each and process each colour channel on a separate thread.

[Hardcoal]

very interesting idea! ill give it a try! thanks

i have no clue about multi threading.. never dealed with it

[Derron]

Have a data portion to work on ... and use a Mutex to protect write accesses to it. Unlock the mutex everytime you are done.

For "numbers" this is not problematic as you can simple have threads eg do
pixels 0-99
pixels 100-199
pixels 200-299
...

So none of these groups overlap. They do not change memory addresses - but straight content of "numbers" in the number array (a pixmap is a row of integers containing RGB(A)).

So perfect for threaded processing.


Yet it is better to describe what you actually are doing - as a pixmap of 2k*2k is not that "slow" to compute each frame, but if you compute a 8k*8k 20 times a frame, then you might run into trouble.


Another idea is to make it "async" - so give it to a thread to process and use the old one until the thread is done (so it might be there in the same frame - or 1000 seconds later).


bye
Ron

[TomToad]

Unfortunately your link is asking me for a password for some reason.  But is it possible to do what you want using shaders?  This will allow you to process your images directly on the GPU, which means fast.

[Derron]

I clicked on the link and it downloaded a PNGSplitter.rar (automatically) and it was able to unpack it.

According to the name he wants to read parts from a pixmap and create a new pixmap out of it. But maybe it is for some live preview or so.

Would be good to know in "abstract" what Hardcoal wants to do exactly.


bye
Ron

[Hardcoal]

Ill fix the link soon

What im doing is taking a tile set single png and turning it into separate pngs

[Derron]

Yes - and this should be "blazing fast" - exception is if you need to find the sprites on your own (eg minimum island size) and then do auto-crop etc.

But this is not strictly readpixel/writepixel slowness then but also the algorithm you use.


So ... assume we have 10 sprites on an image - and you know the coords + dimension of each. Extracting this data into new PNGs, is this then slow for you? I doubt it.

As said _read_ access to TPixmap can be multithreaded without much hassle.


Next to classic "threading" you could use what @Brucey once wrote: some "Workers" (you then just pass your task "split images" to the workers and they spawn as much as required, and once done they spawn new ones if there are still images to strip from the image). Means you do not have a fixed amount of threads you send out to strip image slices but a flexible amount of runners utilizing threads - more on this if interested.

So the more you explain (without loosing yourself in too much implementation details) the more easily we could help and spot issues.


bye
Ron