One line miss problem
-
Hi, I want to do magnification on my window. I set the window extension to doubled. When I draw one line, actually it draws a 2-pixel line on the window. If that line is around the border of the window, it is possible only 1-pixel shown up. Now, if I size the window, windows doesn't invalidate the other pixel of that line which it thinks it was already shown. In other words, windows only invalidate the area by logical coordinate, it doesn't know there are some pixels in that coordinate are missed and need to invalidate again. How do I work it around? Thanks a lot.
-
Hi, I want to do magnification on my window. I set the window extension to doubled. When I draw one line, actually it draws a 2-pixel line on the window. If that line is around the border of the window, it is possible only 1-pixel shown up. Now, if I size the window, windows doesn't invalidate the other pixel of that line which it thinks it was already shown. In other words, windows only invalidate the area by logical coordinate, it doesn't know there are some pixels in that coordinate are missed and need to invalidate again. How do I work it around? Thanks a lot.
I'm not sure I'm following you but when you say "around the border of the window" are you referring to the edge of the client area? Or do you mean the edge of the window? And if so, inside or outside the window? How are you scaling? MM_ANISOTROPIC, MM_ISOTROPIC, or some custom modification that synthesizes this effect? Are you using a double-buffering, offscreen buffering technique (i.e. memDC)? Are you drawing the line using GDI or GDI+? Are you performing Antialiasing? Which function are you using to invalidate with?
-
I'm not sure I'm following you but when you say "around the border of the window" are you referring to the edge of the client area? Or do you mean the edge of the window? And if so, inside or outside the window? How are you scaling? MM_ANISOTROPIC, MM_ISOTROPIC, or some custom modification that synthesizes this effect? Are you using a double-buffering, offscreen buffering technique (i.e. memDC)? Are you drawing the line using GDI or GDI+? Are you performing Antialiasing? Which function are you using to invalidate with?
Thanks for your help. I use memory DC to draw some bitmaps on the client area and offset the viewport origins (if I scroll the window). The line is actually the part of the bitmap around the edge of the client area. I didn't use any graphics techniques, just create a window and set mapping mode by SetMapMode(GetDC(hwnd), MM_ISOTROPIC), its extension by SetWindowExtEx(GetDC(hwnd), 100, 100, NULL) and SetViewportExtEx(GetDC(hwnd), 200, 200, NULL). After resizing the window, I got WM_PAINT messages. I analyze the invalidate rectangles, then found this problem. I use GDI, win32. Maybe no antialiasing. I'm not sure if it was double-buffering.
-
Thanks for your help. I use memory DC to draw some bitmaps on the client area and offset the viewport origins (if I scroll the window). The line is actually the part of the bitmap around the edge of the client area. I didn't use any graphics techniques, just create a window and set mapping mode by SetMapMode(GetDC(hwnd), MM_ISOTROPIC), its extension by SetWindowExtEx(GetDC(hwnd), 100, 100, NULL) and SetViewportExtEx(GetDC(hwnd), 200, 200, NULL). After resizing the window, I got WM_PAINT messages. I analyze the invalidate rectangles, then found this problem. I use GDI, win32. Maybe no antialiasing. I'm not sure if it was double-buffering.
When you change the viewport and window extents, you will suffer from "off by one" errors. This is inherent in how non MM_TEXT mapping modes work and the algebra used for the metric translations. Those errors become evident when you apply offscreen buffering techniques such as described by Petzold, Jones, and in Keith Rule's article here on codeproject. His example claims to support MM_ANISOTROPIC but if you examine his source code, you will find he leaves the viewport and window extents at 1 which is effectively the same as MM_TEXT and when applied to the algebraic equations will not cause off by one errors. Obviously, MM_ANISOTROPIC and MM_ISOTROPIC would be useless if used without setting the extents as this is what provides the scaling. (By the way, that's not a bash on the authors as their code helps greatly, just a matter of factly statement) If you are using a variant of one of the published authors memDC and using MM_ISOTROPIC, this is likely what you are suffering from or will find you are suffering from later. One way to verify this is to turn on "Show windows contents while dragging" in the display properties/appearance tab/effects button. Drag the help/about box from your application over your client area in random paths and if it "smears" or "smudges" your drawings then you are suffering from this. It basically involves the calculation of the clipping rectangle and the fact that there is a LPtoDP and a DPtoLP involved explicitly and indirectly by the windows API functions. If your familiar with the "pigeon hole principle" then you already understand the fact that a round trip could cause a loss of data. Hence the off by one error that leaves a single pixel width not refreshed on the edge of the clipping rectangle. Some people never notice it because they have the "Show windows contents while dragging" turned off so as they resize the window or drag something over it, they only see a tracker rect and not the leftover non refreshed edges. I posted a reply in Keith's article linking to a helpful MSDN article that helped me realize how get past this (somebody didn't like my response there, got a 2 vote probably because I didn't post the code or something). In a nutshell, you need to calculate the rectangle that is used for the bitmap and the blit without any LPtoDP or DPtoLP round trips. here[
-
When you change the viewport and window extents, you will suffer from "off by one" errors. This is inherent in how non MM_TEXT mapping modes work and the algebra used for the metric translations. Those errors become evident when you apply offscreen buffering techniques such as described by Petzold, Jones, and in Keith Rule's article here on codeproject. His example claims to support MM_ANISOTROPIC but if you examine his source code, you will find he leaves the viewport and window extents at 1 which is effectively the same as MM_TEXT and when applied to the algebraic equations will not cause off by one errors. Obviously, MM_ANISOTROPIC and MM_ISOTROPIC would be useless if used without setting the extents as this is what provides the scaling. (By the way, that's not a bash on the authors as their code helps greatly, just a matter of factly statement) If you are using a variant of one of the published authors memDC and using MM_ISOTROPIC, this is likely what you are suffering from or will find you are suffering from later. One way to verify this is to turn on "Show windows contents while dragging" in the display properties/appearance tab/effects button. Drag the help/about box from your application over your client area in random paths and if it "smears" or "smudges" your drawings then you are suffering from this. It basically involves the calculation of the clipping rectangle and the fact that there is a LPtoDP and a DPtoLP involved explicitly and indirectly by the windows API functions. If your familiar with the "pigeon hole principle" then you already understand the fact that a round trip could cause a loss of data. Hence the off by one error that leaves a single pixel width not refreshed on the edge of the clipping rectangle. Some people never notice it because they have the "Show windows contents while dragging" turned off so as they resize the window or drag something over it, they only see a tracker rect and not the leftover non refreshed edges. I posted a reply in Keith's article linking to a helpful MSDN article that helped me realize how get past this (somebody didn't like my response there, got a 2 vote probably because I didn't post the code or something). In a nutshell, you need to calculate the rectangle that is used for the bitmap and the blit without any LPtoDP or DPtoLP round trips. here[