Page 2 of 2
Posted: Fri Mar 23, 2007 5:19 pm
by netmaestro
*pPixels = AllocateMemory(bmpWidth*bmpHeight*3)
So, what should this be then? bmpWidth*bmpHeight*4? Can you provide a picture that makes my code fail, as all my tests are OK? If it isn't right, I certainly would like to fix it.
Posted: Fri Mar 23, 2007 5:51 pm
by srod
I understand now. You're actually reducing the width of the bitmap to make it a multiple of 4. This of course means that you might be losing a few columns of pixels at the far right of the image.
I've tested with a couple of images and that indeed seems to be what is happening.
Instead of adjusting the width of the bitmap, you should increase the amount of memory allocated to give each row a multiple of 4 bytes.
Code: Select all
Procedure Get24BitColors(pBitmap)
; GetObject_(pBitmap, SizeOf(BITMAP), @bmp.BITMAP)
bytesperrow = 4*((3*bmpWidth+3)/4)
*pPixels = AllocateMemory(bytesperrow*bmpHeight)
hDC = GetWindowDC_(#Null)
iRes = GetDIBits_(hDC, pBitmap, 0, bmpHeight, *pPixels, @bmiInfo, #DIB_RGB_COLORS)
ReleaseDC_(#Null, hDC)
ProcedureReturn *pPixels
EndProcedure
You will also need to remove the line
(I love the image by the way!! Pwhooarrrrr...)
Posted: Fri Mar 23, 2007 6:06 pm
by netmaestro
Down, boy!
Ok, as I recall now I had a reason for not caring about the last (max. 3) pixels getting chopped off the right side of the image back when I wrote that procedure. But your solution is better, so I've amended my code to reflect the changes. I'm not 100% sure there isn't a pixel gone from the right side of that photo though, so I'm going to have to stare at it over and over and over..
Posted: Fri Mar 23, 2007 6:11 pm
by srod
Every pixel counts with this image!
Now where was I before being so rudely interrupted?
Oh yes,... phwooooaaaaarrrr.....
(p.s. I wouldn't show that image to fangles; he'll probably explode!)
Posted: Sat Mar 24, 2007 11:58 am
by Tomio
A note only. Nothing new.
It's not good to be fixated to much on one point and ignore the rest.
After having considered the situation once more, it became clear (to me) that it's not worth to save disk save/load time.
This is in short and roughly the time situation:
a)CopyDesktopToImage 0.?%
b)DoSomeThing+Compress 1%
c)SendOverNetwork 98%
e)DoSomeThing+Decompress 1%
f)CreateImage+Display 0%
b)+c) depend stronly on bandwidth and compression, but however it is done, the time for Saveimage/LoadImage can be neglected.
And: the faster the host the more extreme the ratios are.
Though it would look smarter to send the image straight away (after compressing!!) from memory through the net, there was no noticeable time saving doing this.
By the way, I did some time measurements.
I did it on one of those small Win98 clients which are to run the tool.
Perhaps you are interested:
The task was: Grab Screen to Image --> SaveImage --> LoadImage
All timevalues are the mean of 20 runs.
GrabScreenTo Image == 1.32 sec
SaveImage+LoadImage == 0.24 sec BMP == 2359350 Bytes
SaveImage+LoadImage == 2.69 sec JPEG == 162215
SaveImage+LoadImage == 2.8 PackMemory() == 47338 (!)
PackMemory() was with factor=3 (4 took already too long).
So, for me it's obvious: PackMemory + diskfile.
.../tomio
Posted: Sat Mar 24, 2007 12:14 pm
by netmaestro
You're most welcome! Looks like you've got a good handle on your project, good luck with it
Posted: Sat Mar 24, 2007 1:09 pm
by Kale
Brice Manuel wrote:Buggier than Bamberware
lol!
I guess he is still king of the bugs.