{"id":17463,"date":"2009-07-16T10:00:00","date_gmt":"2009-07-16T10:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2009\/07\/16\/separating-the-metadata-from-the-dib-pixels-changing-the-raster-operation\/"},"modified":"2009-07-16T10:00:00","modified_gmt":"2009-07-16T10:00:00","slug":"separating-the-metadata-from-the-dib-pixels-changing-the-raster-operation","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20090716-00\/?p=17463","title":{"rendered":"Separating the metadata from the DIB pixels: Changing the raster operation"},"content":{"rendered":"

\nFor a few days now, we’ve\n\nused the SetDIBitsToDevice<\/code> function\nin conjunction with a precomputed BITMAPINFO<\/code>\nto draw a DIB with an alternate color table<\/a>\nwithout modifying the HBITMAP<\/code><\/a>.\n<\/p>\n

\nThe SetDIBitsToDevice<\/code> function operates like\na BitBlt<\/code> with raster operation SRCCOPY<\/code>.\nIf you want another raster operation, you can use\nStretchDIBits<\/code>, which has a final raster operation parameter.\nDespite its name, you don’t have to stretch with StretchDIBits<\/code>.\nJust pass a source and destination of equal size, and you’ve performed\na NOP stretch, but you get the benefit of the raster operation.\n<\/p>\n

\nvoid\nPaintContent(HWND hwnd, PAINTSTRUCT *pps)\n{\n if (g_pvBits) {\n    StretchDIBits<\/font>(pps->hdc, 0, 0,\n                      g_bmiGray.bmiHeader.biWidth,\n                      g_bmiGray.bmiHeader.biHeight, 0, 0,\n                      g_bmiGray.bmiHeader.biWidth,\n                      g_bmiGray.bmiHeader.biHeight,<\/font>\n                      g_pvBits,\n                     (BITMAPINFO*)&g_bmiGray, DIB_RGB_COLORS,\n                      NOTSRCCOPY<\/font>);\n }\n}\n<\/pre>\n
\nI changed the call from SetDIBitsToDevice<\/code>\nto StretchDIBits<\/code>,\nsetting the source and destination rectangles to the same size\n(so no actual stretching occurs),\nand specifying a raster operation of NOTSRCCOPY<\/code>\nso the result on screen is a negative grayscale.\n<\/p>\n
\nSome people may object to performing a stretch operation\nand requesting no stretching, but that’s perfectly fine.\nAt least in this case, GDI is not stupid.\nIf you ask it to perform a stretch operation\nbut pass parameters that don’t do any stretching, it will\noptimize this to a non-stretching operation.\nYou don’t need to hand-optimize it.\nInstead of writing\n<\/p>\n
\nif (cxSrc == cxDst && cySrc == cyDst) {\n BitBlt(hdc, xDst, yDst, cxDst, cyDst,\n        hdcSrc, xSrc, ySrc, dwRop);\n} else {\n StretchBlt(hdc, xDst, yDst, cxDst, cyDst,\n            hdcSrc, xSrc, ySrc, cxSrc, cySrc, dwRop);\n}\n<\/pre>\n
\n… just go straight to the StretchBlt<\/code>:\n<\/p>\n
\nStretchBlt(hdc, xDst, yDst, cxDst, cyDst,\n           hdcSrc, xSrc, ySrc, cxSrc, cySrc, dwRop);\n<\/pre>\n
\nThe StretchBlt<\/code> function will convert the\noperation to a BitBlt<\/code> if cxSrc == cxDst<\/code>\nand cySrc == cyDst<\/code>.\nYou don’t have to hand-optimize it.\nThe GDI folks hand-optimized it for you.\n<\/p>\n
\n(In fact, for a long time,\nthe SetDIBitsToDevice<\/code> function simply called\nStretchDIBits<\/code>, saying that the input and\noutput rectangles were the same size,\nand StretchDIBits<\/code> detected the absence of stretching\nand used an optimized code path.\nConsequently,\n“optimizating” the code by calling\nSetDIBitsToDevice<\/code>\nwas actually a pessimization.)<\/p>\n
\nBack to StretchDIBits<\/code>.\nSo far, we’ve been drawing the entire bitmap at the upper left\ncorner of the destination device context.\nThe last remaining feature of BitBlt<\/code> is\nthe ability to draw a rectangular chunk of a source bitmap\nat a destination location,\nso let’s do that.\nWe’ll draw the bottom right corner of the bitmap in\nthe bottom right corner of the window,\nwith negative colors,\nand just to show we can<\/i>, we’ll also stretch it.\n<\/p>\n
\nvoid\nPaintContent(HWND hwnd, PAINTSTRUCT *pps)\n{\n if (g_pvBits) {\n  RECT rc;\n  GetClientRect(hwnd, &rc);\n  int cxChunk = g_bmiGray.bmiHeader.biWidth \/ 2;\n  int cyChunk = g_bmiGray.bmiHeader.biHeight \/ 2;\n  StretchDIBits(pps->hdc, rc.right - cxChunk * 2,\n                rc.bottom - cxChunk * 2,\n                cxChunk * 2, cyChunk * 2,\n                g_bmiGray.bmiHeader.biWidth - cxChunk,\n                g_bmiGray.bmiHeader.biHeight - cyChunk,\n                cxChunk, cyChunk,\n                g_pvBits, (BITMAPINFO*)&g_bmiGray,\n                DIB_RGB_COLORS, NOTSRCCOPY);<\/font>\n }\n}\n<\/pre>\n
\nSo far, we’ve been operating on DIB pixels that are\nheld inside a DIB section.\nBut there’s no requirement that the bits passed to\nStretchDIBits<\/code> come from an actual DIB section.\nWe’ll look at the total disembodiment of DIBs next time,\nas well as looking at some unexpected consequences of all our game-playing.<\/p>\n","protected":false},"excerpt":{"rendered":"
For a few days now, we’ve used the SetDIBitsToDevice function in conjunction with a precomputed BITMAPINFO to draw a DIB with an alternate color table without modifying the HBITMAP. The SetDIBitsToDevice function operates like a BitBlt with raster operation SRCCOPY. If you want another raster operation, you can use StretchDIBits, which has a final raster […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-17463","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
For a few days now, we’ve used the SetDIBitsToDevice function in conjunction with a precomputed BITMAPINFO to draw a DIB with an alternate color table without modifying the HBITMAP. The SetDIBitsToDevice function operates like a BitBlt with raster operation SRCCOPY. If you want another raster operation, you can use StretchDIBits, which has a final raster […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/17463","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=17463"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/17463\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=17463"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=17463"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=17463"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}