GM_DrawLayerList with 32 bit destination DC?
jkenneally
Global Mapper UserTrusted User
Hello,
I'm working on a bit of code to render a raster map to a 32 bit DIB (Device Independent Bitmap) through the Global Mapper SDK, version v1.34.
I had previously had this working fine rendering to a 24 bit RGB DIB, but since upgrading to using a destination image with alpha, global mapper always seems to set the alpha component value to 0 (ie transparent) when it performs its render. Otherwise it appears the render is succeeding (ie my destination bitmap RGB component values seem to be getting updated by the render, and the call is returning success).
I have tried setting the high order byte of the COLORREF being passed to GM_SetBackgroundColor() to 255 (ie 0xFFFFFFFF) to force the GM_DrawLayerList() call to erase the background to all white, opaque pixels. I do send the erase background flag to GM_DrawLayerList.
Is there some inherent limitation to GM_DrawLayerList that is causing it to reset my alpha component to 0 through-out the image? Maybe some configuration option I'm missing? I have been looking more closely at the code I use to create and initialize my bitmap using the win32 CreateDIBSection() call, but so far that seems to be correct and the bitmaps are otherwise behaving correctly.
I even tried manually initializing the bitmap surface to all 255's before calling GM_DrawLayerList. I was hoping maybe the alpha values just weren't getting written to by Global Mapper, but they do explicitly get reset to 0 during the render.
Thanks!
I'm working on a bit of code to render a raster map to a 32 bit DIB (Device Independent Bitmap) through the Global Mapper SDK, version v1.34.
I had previously had this working fine rendering to a 24 bit RGB DIB, but since upgrading to using a destination image with alpha, global mapper always seems to set the alpha component value to 0 (ie transparent) when it performs its render. Otherwise it appears the render is succeeding (ie my destination bitmap RGB component values seem to be getting updated by the render, and the call is returning success).
I have tried setting the high order byte of the COLORREF being passed to GM_SetBackgroundColor() to 255 (ie 0xFFFFFFFF) to force the GM_DrawLayerList() call to erase the background to all white, opaque pixels. I do send the erase background flag to GM_DrawLayerList.
Is there some inherent limitation to GM_DrawLayerList that is causing it to reset my alpha component to 0 through-out the image? Maybe some configuration option I'm missing? I have been looking more closely at the code I use to create and initialize my bitmap using the win32 CreateDIBSection() call, but so far that seems to be correct and the bitmaps are otherwise behaving correctly.
I even tried manually initializing the bitmap surface to all 255's before calling GM_DrawLayerList. I was hoping maybe the alpha values just weren't getting written to by Global Mapper, but they do explicitly get reset to 0 during the render.
Thanks!
Comments
-
The SDK isn't going to directly do anything with the alpha values. What happens is that internally the SDK renders to a 24-bit RGB DIB as an offscreen bitmap, then does a BitBlt to your provides DC. I'm guessing the BitBlt from a 24-bit RGB offscreen bitmap to a 32-bit RGBA one always fills the alpha channel with 0.
I would suggest setting the alpha after the GM_DrawLayerList call.
Let me know if I can be of further assistance.
Thanks,
Mike
Global Mapper Support
support@globalmapper.com -
Thanks for the quick reply as usual, Mike.
I think you may be right about Bitblit filling my 32 bit image with 0's for alpha given the lack of alpha channel in the src image. I can definitely reset my alpha values after the render, but unfortunately I think this is going to create a noticeable performance hit.
Just out of curiosity, would you consider switching to using a 32-bit internal bitmap in the future? You'd be using a bit more memory, etc, but with the right blit function 32 bit users could avoid having to touch each pixel of the image after a call to GM_DrawLayer*. Developers using 24 bit images would in theory see no change.
Cheers! -
I don't think we would want to switch to a 32-bit internal bitmap in the future because some of the internal bitmaps can be huge and adding another 33% to memory usage wouldn't be inconsequential. Plus since the SDK wouldn't use the original alpha values anyway they would be reset anyway.
I think it will actually be very fast for you to copy over the original alpha values after calling GM_DrawLayerList, probably well under 100 ms.
Thanks,
Mike
Global Mapper Support
support@globalmapper.com -
Yeah it actually didn't turn out to be as great a performance hit as I was expecting relative to the overall render time. I can also see how the additional memory for the alpha channel might be a problem if your bitmaps are really large. Having said that, 50-100ms is a long time for a single function of a render pipeline.
Thanks!
Categories
- 12.7K All Categories
- 5.6K Features Discussion
- 342 Downloading Imagery
- 1.3K Elevation Data
- 380 Georeferencing Imagery Discussion
- 628 GM Script Language
- 53 User Scripts
- 113 GPS Features
- 414 Projection Questions
- 819 Raster Data
- 1.3K Vector Data
- 6.6K Support
- 177 Announcement and News
- 908 Bug Report
- 558 SDK
- 1.2K Suggestion Box
- 3.7K Technical Support
- 562 Other Discussion
- 129 GIS Data Sources
- 27 Global Mapper Showcase
- 233 How I use Global Mapper
- 107 Global Mapper Forum Website