Transparent lines in C
-
If i only have C and i want to draw a transparent line the only solution i can think of: - create a memoryDC and a compatiblebitmap - Draw the line on the memoryDC - Create a region that occupies the drawed line only - Set this region to the DC - copy memoryDC to DC transparently using Alphablend() For a few lines this could work, but when drawing 100-dreds of lines the overhead is just too much. Is there any more clever approach? Rozis
-
If i only have C and i want to draw a transparent line the only solution i can think of: - create a memoryDC and a compatiblebitmap - Draw the line on the memoryDC - Create a region that occupies the drawed line only - Set this region to the DC - copy memoryDC to DC transparently using Alphablend() For a few lines this could work, but when drawing 100-dreds of lines the overhead is just too much. Is there any more clever approach? Rozis
-
Code-o-mat wrote:
I don't know how Rozis wrote: If i only have C limits this but try using GDI+[^].
It does: C does not know about the concept of classes while GDI+ is a class oriented API. GDI+ has also a function interface but MS itself disencourages this... If there are any people here who have experience with this function interface of GDI+, please give me a yell... Rozis
-
Code-o-mat wrote:
I don't know how Rozis wrote: If i only have C limits this but try using GDI+[^].
It does: C does not know about the concept of classes while GDI+ is a class oriented API. GDI+ has also a function interface but MS itself disencourages this... If there are any people here who have experience with this function interface of GDI+, please give me a yell... Rozis
I can also think of 2 alternatives but both include doing the line drawing manually. So you write the line draw algorithm yourself and use GetPixel and SetPixel to perform the blending. You use GetPixel to get the color of your "target", calculate a new COLORREF using this color and your line color and blending, then you use SetPixel to display the pixel. This method will surely be slow since Get/SetPixel are slugs. The other i can think of is using a device-independent bitmap as a kind of "backbuffer", you place your target image onto this bitmap, do the line drawing and blending manually by directly reading-writing the pixel data of the bitmap (i suggest a 32 bit bitmap for a better speed) and then when you are done drawing all those lines, blit this buffer to the screen. This should be faster.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Sometimes you just have to hate coding to do it well. <
-
I can also think of 2 alternatives but both include doing the line drawing manually. So you write the line draw algorithm yourself and use GetPixel and SetPixel to perform the blending. You use GetPixel to get the color of your "target", calculate a new COLORREF using this color and your line color and blending, then you use SetPixel to display the pixel. This method will surely be slow since Get/SetPixel are slugs. The other i can think of is using a device-independent bitmap as a kind of "backbuffer", you place your target image onto this bitmap, do the line drawing and blending manually by directly reading-writing the pixel data of the bitmap (i suggest a 32 bit bitmap for a better speed) and then when you are done drawing all those lines, blit this buffer to the screen. This should be faster.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Sometimes you just have to hate coding to do it well. <
[Message Deleted]
-
[Message Deleted]
I assume you did not intend to target that post at me.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Sometimes you just have to hate coding to do it well. <
-
If i only have C and i want to draw a transparent line the only solution i can think of: - create a memoryDC and a compatiblebitmap - Draw the line on the memoryDC - Create a region that occupies the drawed line only - Set this region to the DC - copy memoryDC to DC transparently using Alphablend() For a few lines this could work, but when drawing 100-dreds of lines the overhead is just too much. Is there any more clever approach? Rozis
May be you will have to create 32bpp DIB section and make all your drawing on it. And finally use AlphaBlend() on target DC.
-
I assume you did not intend to target that post at me.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Sometimes you just have to hate coding to do it well. <
I'll try to answer both... Alphablend() has a parameter that determines a global transparency. Suppose I want 2 lines with different transparencies i must use Alphablend() 2 times. And drawing 2 times tranparently to the screen will change the original pixels (those that are not from the lines). In other words: I can copy the screen to the memoryDC, draw the line and alphablend it to the screen but then all pixels are changed. This is why a regionobject is required. So the solution of Rejeesh can not work. The first suggestion of Code-o-mat is too slow. But his 2nd approach may have some opportunities. If i understand you well Code-o-mat essentially you say to me: manipulate the alpha-channel according to the line drawn... Thus if i could draw the line directly in the alpha-channel my problem would be solved. Unfortunally there's not such function... but maybe i can write one... Maybe an approach can be: create a memoryDC, a 32-BPP bitmap and an addional 8-bit black and white bitmap. Draw the lines on the 8-bit bitmap (and also on the 32-bit bitmap) and finally merge the 8-bit image as an alpha-channel to the 32-bit bitmap. This means: no regions needed, no manual line draws and only one time comsuming operation (the merging of the alpha-channel. Sounds promissing! Anyone any better ideas?
-
I'll try to answer both... Alphablend() has a parameter that determines a global transparency. Suppose I want 2 lines with different transparencies i must use Alphablend() 2 times. And drawing 2 times tranparently to the screen will change the original pixels (those that are not from the lines). In other words: I can copy the screen to the memoryDC, draw the line and alphablend it to the screen but then all pixels are changed. This is why a regionobject is required. So the solution of Rejeesh can not work. The first suggestion of Code-o-mat is too slow. But his 2nd approach may have some opportunities. If i understand you well Code-o-mat essentially you say to me: manipulate the alpha-channel according to the line drawn... Thus if i could draw the line directly in the alpha-channel my problem would be solved. Unfortunally there's not such function... but maybe i can write one... Maybe an approach can be: create a memoryDC, a 32-BPP bitmap and an addional 8-bit black and white bitmap. Draw the lines on the 8-bit bitmap (and also on the 32-bit bitmap) and finally merge the 8-bit image as an alpha-channel to the 32-bit bitmap. This means: no regions needed, no manual line draws and only one time comsuming operation (the merging of the alpha-channel. Sounds promissing! Anyone any better ideas?
Your idea sounds interesting but the merging process might become slow with bigger images.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Sometimes you just have to hate coding to do it well. <
-
Your idea sounds interesting but the merging process might become slow with bigger images.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Sometimes you just have to hate coding to do it well. <
Code-o-mat wrote:
Your idea sounds interesting but the merging process might become slow with bigger images.
True, but my inital approach wasn't free either :) And maybe you din't realized that, but had to do all the things per line. So 100 lines was 100 buffers, 100 regions, ... Now it seems i have: 1 buffer, no regions, and one time consumer. And the good news is the time consumer has no mults or divides, just some bit shifting. I'm sure performance will be much better... bet it will have a performance like a graphic filter (like emboss for ex.). I'll try this out in the next days - thanks for the ideas... Rozis
-
Code-o-mat wrote:
I don't know how Rozis wrote: If i only have C limits this but try using GDI+[^].
It does: C does not know about the concept of classes while GDI+ is a class oriented API. GDI+ has also a function interface but MS itself disencourages this... If there are any people here who have experience with this function interface of GDI+, please give me a yell... Rozis
-
Rozis wrote:
but MS itself disencourages this...
Microsoft discourages C++, too, but don't let that stop you. :laugh:
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
Tim Craig wrote:
Rozis wrote: but MS itself disencourages this... Microsoft discourages C++, too, but don't let that stop you.
Yep. It says: "Microsoft Windows GDI+ exposes a flat API that consists of about 600 functions, which are implemented in Gdiplus.dll and declared in Gdiplusflat.h. The functions in the GDI+ flat API are wrapped by a collection of about 40 C++ classes. It is recommended that you do not directly call the functions in the flat API. Whenever you make calls to GDI+, you should do so by calling the methods and functions provided by the C++ wrappers. Microsoft Product Support Services will not provide support for code that calls the flat API directly." What i figure out of their documentation is that the complete GDI+ classes are internally handled by their 'flat API'. This probably means: the flat api will change without any notice. Maybe the reason they discourages C++ is that they seem to be afraid of classes.:cool: