I am solving a task where I need to convert Bitmap data to custom image format. I am currently doing this: [em]Bitmap.GetBitmap()[/em] => RLP => byte array (custom format) => send. I need to achieve the best performance possible. I have one crazy idea, please tell me what you think about it : .
I want to access Bitmap object directly from RLP without using [em]GetBitmap()[/em] first. [em]GetBitmap()[/em] allocates new array every single time you call it and you cannot specify it to store data in already predefined byte array. Hence I get GC being called too often if I call [em]GetBitmap()[/em], for example, 250 times in 10 seconds. I also expect to achieve better speed by eliminating calls to [em]GetBitmap()[/em].
Maybe GHI team could add an option to pass not only integers, strings, arrays etc. to RLP, but objects as well?
By the way, during my investigation, if my idea could work, I came across [em]GHI.Utilities.Bitmap[/em] class. My first thought was that GHI guys have already partially implemented my idea, but I was quickly disappointed when I found out that they are using [em].GetBitmap()[/em] first and then are doing some byte array manipulation internally. There are two things I would like to point out about this class:
- If you call [em]Convert(Bitmap bitmap, Bitmaps.BitsPerPixel bpp)[/em], [em]GetBitmap()[/em] is being called 3 times! That’s painfully slow, plus you get memory fragmentation. Why not use [em]bitmap.Width * bitmap.Height * 4[/em] instead of [em]bitmap.GetBitmap().Length[/em]?
- Error message is not accurate:
if (outputBuffer.Length != Bitmaps.RequiredBufferSize(bitmap, bpp))
throw new ArgumentOutOfRangeException("outputBuffer", "outputBuffer is too small. Call RequiredBufferSize to determine how large it must be");
Years ago I requested a better access to the raw bitmap data but nothing happened This is even worse that you think as a performance killer. The bitmap a 16bit but get bitmap get you 32bit! So much for “embedded systems” resource saving!
You will not be able to get the bitmap directly. Where do images come from to begin with and in what format?
I’d love to be able to do something similar to enhance my smoothline code.
At the moment I think I need to do .getbitmap to get a byte array to pass to RLP for drawing and then create a bitmap file with header to load into an bitmap object.
In full fat dot net I would use lockbits.
When you pass an array to RLP, you effectively pass a pointer to it. Why cannot you pass a pointer to Bitmap object?
Most of the time it is an empty Bitmap + [em]DrawText()[/em], [em]DrawLine()[/em] etc.
So you are drawing a bitmap locally using the bitmap class. Then you want to generate a special format class out of it?
@ iamin - Bitmaps can be passed to RLP in the next release. You’ll get a buffer that represents the internal pixel data in RGB 565 format. The usual rules for RLP arrays still hold. We also added some helper methods to the Bitmaps class to get and set the internal bitmap buffer from C# without making a copy. Lastly, calls to GetBitmap were removed from the other bitmap functions.
@ John - is this a GHI or msoft effort? Great news either way.
Will there be a Beta or RC of the next SDK?
@ Simon from Vilnius - Not planning on doing a beta at this time, it’ll be a full release.
And another Tinybooter update? :wall:
@ Simon from Vilnius - As of now, just for Hydra which I believe will be optional and G400 which I believe will not be optional, though I am not sure yet.
Oh God… Here comes another “Tinybooter update is optional as of now” :wall: For… I don’t know? 4th release? 5th?..
Tiny booter did not change in last release and will not change in this release! Why do you think it will change?
Did it not? Then what about 4.3.5 for G400?
Pure deduction — you’ve changed it every release since G400 was out. If deduction is not enough, then what about John?
Back on topic… I hope this new RLP feature will not break compatibility in any way?..
@ Simon from Vilnius - It won’t. Just pass a bitmap object to invoke like you do for every other supported data type and it’ll appear in the args array down on the native side. Everything else works exactly as it did before.
@ Simon from Vilnius - try to be more positive and it may finally happen
@ John - Thank you! I feel like dreaming. Cannot wait for the next release.