Mike Versteeg If you need speed, why are you using the VCL's TBitmap?
TBitmap is a reasonably inefficient wrapper around a Windows bitmap that was made for ease of use, not speed.
I am not dissing TBitmap - it is a good friend.
If you want fast, TBitmap is not it (and neither is the GDI).
Can I bore you with a little background about fast and the GDI (and offer to solve your problem too)?
I have been writing GDI drivers for 30 years now (since the Windows 0.8 beta). I helped designed the first full screen animation engine for Windows (used by Disney. Warner and others). I know this stuff pretty well.
Fast can be done, and can done without a GPU (or the GDI).
A quick story you may find interesting related to color conversion, and speed.
I just posted a demo of my new frame buffer engine that's getting over 1,400 some odd frames per second to a 640x480 Delphi 6 Paintbox using a single core (no threading), and completely UN-accelerated powered by 10 year old laptop.
It is generating and filling multiple tiles (with custom offsets), on the fly, while doing multiple alpha transparency layers, with some of the alpha paths layers transformed in 2-5 D, all scan converted and moving all over the place.
That is one a heck of lot of scan conversion and pixel manipulations (conversions) going on (in no uncertain terms).
Actually, that is a unheard of speed in the industry (I only know that because I have been doing this for 30 years and is something I try to keep up with).
There is no smoke and mirrors, no assembler, it's all 100% native pascal code, crosses platforms, crosses processors, crosses compilers (I love you FPC). In short, it compiles and runs anywhere on anything, and does a lot of color conversion (really fast).
Funny, I still have 8x speed-up of the scan converter to add.
For Windows, I am using the fastest GDI call to get the resulting pixels to the driver in the shortest possible time:
SetDIBitsToDevice() using the native bit format and orientation.
Interesting: That one GDI call takes well over 40% of the clock time of all that work (as measured by the Windows high resolution timer) just to transfer the resulting bits from the framebuffer to the display.
That's a pretty sad statement (for the GDI). That 40% is also pretty universal among "quality" drivers. hmm.
I really need to go take a look to see how many transfers and manipulations I am doing per pixel and compare that the one pixel GDI has simply to transfer to the display driver.
Considering I am transferring pixels from a half dozen other frame buffers into one, and scan converting paths with 2-5 D transforms on top of that (with transparency), not to mention the tiling operations going on, I can tell you right now, its going to be a very sad ratio for the GDI.
All that said, YCbCr conversion is not huge deal to do quickly, nor is a big deal (or slow) to stuff the bits to and from a TBitmap.
Just don't use TBitmap (or the GDI) to do it!
I eat this sort of thing for lunch everyday.
If your really interested in fast, let me know. I'm hungry and looking for work (even very small bits of work). This can be done on the cheap.
Plug: I specialize in high speed graphics, PDF, printing (and drivers - yucky stuff that is). I guess while I am plugging my self, I should mention I am also a former Borland engineer (the folks that originally made Delphi).
I have been kinda quite about what I am up to (slowly getting ready to release some new products for Delphi)... like that framebuffer engine that may work very well for you.
I have sent out a few private invites so far, but but "what the hecht" (a pun on my last name)...
If your interested in taking a look at this silly little framebuffer engine and what I am doing with it, below is a link where you will find a little info, along with a very silly and somewhat unimpressive sample video (made in very slow motion because the human eye cannot see what is going on at 1400 plus frames per second).
Look for the one with a picture of myself and my lovely wife spinning around in space at 1400 FPS.
I hope I have not bored you too badly with my long winded story. Give me a ring if you like. I can get your color conversion done in short order.
Mike Versteeg this library for Lazarus could bring some light sourceforge.net - Lazarus Code and Component Repository
ReplyDeleteHeinz Toskano thanks, but speed is very important so I prefer to stick to the VCL bitmap. Or D2D if it ever gets implemented properly.
ReplyDeleteyou may try Graphics32 (https://github.com/graphics32/graphics32)
ReplyDeletethat's why libraries are supposed to help with. they fill the gap you can't do otherwise.
ReplyDeleteMike Versteeg If you need speed, why are you using the VCL's TBitmap?
ReplyDeleteTBitmap is a reasonably inefficient wrapper around a Windows bitmap that was made for ease of use, not speed.
I am not dissing TBitmap - it is a good friend.
If you want fast, TBitmap is not it (and neither is the GDI).
Can I bore you with a little background about fast and the GDI (and offer to solve your problem too)?
I have been writing GDI drivers for 30 years now (since the Windows 0.8 beta). I helped designed the first full screen animation engine for Windows (used by Disney. Warner and others). I know this stuff pretty well.
Fast can be done, and can done without a GPU (or the GDI).
A quick story you may find interesting related to color conversion, and speed.
I just posted a demo of my new frame buffer engine that's getting over 1,400 some odd frames per second to a 640x480 Delphi 6 Paintbox using a single core (no threading), and completely UN-accelerated powered by 10 year old laptop.
It is generating and filling multiple tiles (with custom offsets), on the fly, while doing multiple alpha transparency layers, with some of the alpha paths layers transformed in 2-5 D, all scan converted and moving all over the place.
That is one a heck of lot of scan conversion and pixel manipulations (conversions) going on (in no uncertain terms).
Actually, that is a unheard of speed in the industry (I only know that because I have been doing this for 30 years and is something I try to keep up with).
There is no smoke and mirrors, no assembler, it's all 100% native pascal code, crosses platforms, crosses processors, crosses compilers (I love you FPC). In short, it compiles and runs anywhere on anything, and does a lot of color conversion (really fast).
Funny, I still have 8x speed-up of the scan converter to add.
For Windows, I am using the fastest GDI call to get the resulting pixels to the driver in the shortest possible time:
SetDIBitsToDevice() using the native bit format and orientation.
Interesting: That one GDI call takes well over 40% of the clock time of all that work (as measured by the Windows high resolution timer) just to transfer the resulting bits from the framebuffer to the display.
That's a pretty sad statement (for the GDI). That 40% is also pretty universal among "quality" drivers. hmm.
I really need to go take a look to see how many transfers and manipulations I am doing per pixel and compare that the one pixel GDI has simply to transfer to the display driver.
Considering I am transferring pixels from a half dozen other frame buffers into one, and scan converting paths with 2-5 D transforms on top of that (with transparency), not to mention the tiling operations going on, I can tell you right now, its going to be a very sad ratio for the GDI.
All that said, YCbCr conversion is not huge deal to do quickly, nor is a big deal (or slow) to stuff the bits to and from a TBitmap.
Just don't use TBitmap (or the GDI) to do it!
I eat this sort of thing for lunch everyday.
If your really interested in fast, let me know. I'm hungry and looking for work (even very small bits of work). This can be done on the cheap.
Plug: I specialize in high speed graphics, PDF, printing (and drivers - yucky stuff that is). I guess while I am plugging my self, I should mention I am also a former Borland engineer (the folks that originally made Delphi).
I have been kinda quite about what I am up to (slowly getting ready to release some new products for Delphi)... like that framebuffer engine that may work very well for you.
I have sent out a few private invites so far, but but "what the hecht" (a pun on my last name)...
If your interested in taking a look at this silly little framebuffer engine and what I am doing with it, below is a link where you will find a little info, along with a very silly and somewhat unimpressive sample video (made in very slow motion because the human eye cannot see what is going on at 1400 plus frames per second).
ReplyDeleteLook for the one with a picture of myself and my lovely wife spinning around in space at 1400 FPS.
I hope I have not bored you too badly with my long winded story. Give me a ring if you like. I can get your color conversion done in short order.
Here is the link:
ÜberPDF