none
[MS-RDPCR2] - Glyph Runs

    Question

  • I am implementing the Composited Remoting V2 protocol [MS-RDPCR2] and I have hit a wall when implementing glyph runs. Several details seem to be missing from the documentation.

    2.2.7.65 MILCMD_GLYPHRUN_CREATE:
    Q1. How is the PrecontrastLevel field used? The documentation simply states that this is an integer value between 1 and 6 and is used to thicken or thin the glyphs. There are no details on the algorithm used to thicken/thin the glyphs.
    Q2. Sometimes I am getting glyph indices with huge values such as 0x3FF00000. Am I correct in using only the least significant 16 bits?

    2.2.7.75 MILCMD_GLYPHBITMAP or 2.2.3.6 MilGlyphBitmap:
    Q3. The "width" and "height" fields seem to be swapped. For example, if the "width" field is 15 pixels and the "height" field is 136 pixels, the actual glyph bitmap is 136 pixels wide and 15 pixels high! Can anyone confirm that this is a documentation error?
    Q4. Similar to Q3: The "horOriginX" and "horOriginY" fields seem to be swapped.
    Q5. The documentation states that the "bitmapElements" field (see 2.2.3.6 MilGlyphBitmap) is an array of bitmap elements each 1 bit in length. However it seems to be an array of 8-bit values instead, i.e. the bitmap data is 8 bits per pixel instead of 1 bit per pixel! How should the 8 bits for each pixel be interpreted?
    Q6. When interpreting the glyph data as an 8-bpp image (136 x 15 pixels in this case) using a grayscale palette (256 shades of gray), the text contained in the image is recognizable but the size of the text is wrong and the colors are wrong. Even stranger, the first character of the text is at the very end! For example, the text is "dministrator: Command Prompt A" (notice the "A" at the end instead of at the front). More precisely, the "A" is 5 pixels wide; the first 4 pixels are at the end but 1 pixel is at the front! Can anyone explain this? Below is the actual protocol data received in MILCMD_GLYPHCACHE_ADDBITMAPS.

    38 08 00 00  messageSize     (2104)  (see 2.2.7.63 MILCMD_GLYPHCACHE_ADDBITMAPS)
    52 00 00 00  controlCode     (  82)
    01 00 00 00  targetResource  (   1)
    00 00 00 00  FontFaceHandle  (   0)
    01 00 00 00  GlyphCount      (   1)
    18 00 00 00  reserved0       (  24)  (see 2.2.7.75 MILCMD_GLYPHBITMAP)
    00 00 00 00  reserved1       (   0)
    00 00 00 00  reserved2       (   0)
    F8 FF FF FF  horOriginX      (  -8)
    00 00 00 00  horOriginY      (   0)
    00 00 00 00  horAdvance      (   0)
    00 00 00 00  verOriginX      (   0)
    29 04 00 00  verOriginY      (1065)
    0F 00 00 00  width           (  15)
    88 00 00 00  height          ( 136)
    00 00 00 00  stride          (   0)
    
    2040 bytes of data follow:
    
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F8 07
    00 00 00 00 00 E0 07 00 00 00 00 00 00 00 00 E0 1F 00 00 00 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F8 FF 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC 00 00 00 00 FC FF FF 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3E 1F
    00 00 00 00 00 E0 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 03 00 00 00 00 00 00 00 00 00 F8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 1F 00 F0 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC 00 00 00 00 FC 00 80 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3F 00 00 00 00 00 80 0F 7C
    00 00 00 00 00 E0 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 03 00 00 00 00 00 00 00 00 00 F8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC 00 00 00 00 FC 00 00 FC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3F 00 00 00 00 00 E0 03 F0
    01 00 00 FE FF E3 07 00 3F FC FF 01 F8 FF 00 C0 0F 00 3F FC FF 03 00 7E 00 C0 FF 7F C0 FF FF 07 F8 E1 3F E0 FF FF 07 E0 FF FF 03 C0 FF FF 0F 00 F0 C3 7F F0 03 00 00 80 1F 00 00 00 00 00 FC FF FF 00 00 3F FC FF 01 F8 FF 00 C0 0F FF 7F 00 FE 3F 00 E0 FF FF 07 00 7E F8 FF 07 00 C0 FF 7F FC 00 00 00 00 FC 00 00 FC 00 FC F0 1F 80 FF FF 1F 00 E0 87 FF 3F 00 FF 1F 00 F8 E1 FF 7F 00 FC FF 7F 00 00 00 00 FC 00 C0
    07 00 F0 07 00 FC 07 00 BF 03 E0 FF 07 E0 07 C0 0F 00 FF 03 C0 1F 00 7E 00 7E 00 00 00 F0 03 00 F8 1F 00 00 00 80 3F 00 F8 01 00 FE 00 00 FC 01 F0 3F 00 F0 03 00 00 C0 0F 00 00 00 00 E0 0F 00 C0 1F 00 BF 03 E0 FF 07 E0 07 C0 EF 00 F8 FF 01 F8 01 00 00 80 3F 00 FE 07 80 3F 00 FE 00 80 FF 00 00 00 00 FC 00 00 3F 00 FC 0F 00 FC 01 00 F8 03 E0 77 00 FC FF 00 FC 00 F8 1F 00 F8 07 00 3F 00 00 00 00 00 3F 00 00
    3F 00 FC 00 00 E0 07 00 7F 00 80 1F 00 C0 0F C0 0F 00 3F 00 00 3F 00 7E 00 80 0F 00 00 F0 03 00 F8 01 00 80 FF FF 3F 00 F8 01 80 1F 00 00 E0 07 F0 03 00 00 00 00 00 C0 0F 00 00 00 00 F8 01 00 00 7E 00 7F 00 80 1F 00 C0 0F C0 1F 00 E0 07 00 F0 03 80 FF FF 3F 00 7E 00 00 7E 80 1F 00 00 FC 00 00 00 00 FC FF FF 01 00 FC 00 00 3F 00 00 C0 0F E0 0F 00 F0 03 00 F8 01 F8 01 00 C0 0F 00 3F 00 00 00 00 C0 FF FF FF
    FF 00 FC 00 00 E0 07 00 3F 00 80 1F 00 C0 0F C0 0F 00 3F 00 00 3F 00 7E 00 00 F0 7F 00 F0 03 00 F8 01 00 FC 01 00 3F 00 F8 01 80 1F 00 00 E0 07 F0 03 00 00 00 00 00 00 7F 00 00 00 00 F8 01 00 00 7E 00 3F 00 80 1F 00 C0 0F C0 0F 00 E0 07 00 F0 03 FC 01 00 3F 00 7E 00 00 7E 80 1F 00 00 FC 00 00 00 00 FC 00 00 00 00 FC 00 00 3F 00 00 C0 0F E0 07 00 F0 03 00 F8 01 F8 01 00 C0 0F 00 3F 00 00 00 00 F0 03 00 00
    F8 03 F8 07 00 FF 07 00 3F 00 80 1F 00 C0 0F C0 0F 00 3F 00 00 3F 00 7E 00 00 00 F8 01 F0 03 00 F8 01 00 7E 00 C0 3F 00 F8 01 00 FE 01 00 FC 01 F0 03 00 F0 03 00 00 00 F8 0F 00 00 0E E0 1F 00 C0 1F 00 3F 00 80 1F 00 C0 0F C0 0F 00 E0 07 00 F0 03 7E 00 C0 3F 00 7E 00 00 7E 00 FF 00 E0 FF 00 00 00 00 FC 00 00 00 00 FC 00 00 FC 03 00 F8 03 E0 07 00 F0 03 00 F8 01 F8 0F 00 F8 03 00 3F 00 00 00 00 FC 00 00 00
    C0 0F 00 FF FF E1 07 00 3F 00 80 1F 00 C0 0F C0 0F 00 3F 00 00 3F 00 7E 00 FE FF 0F 00 80 FF 07 F8 01 00 C0 FF 3F 3F 00 C0 FF 03 C0 FF FF 0F 00 F0 03 00 F0 03 00 00 00 00 FC FF FF 01 00 FC FF FF 00 00 3F 00 80 1F 00 C0 0F C0 0F 00 E0 07 00 F0 03 C0 FF 3F 3F 00 7E 00 00 7E 00 E0 FF 3F FC 00 00 00 00 FC 00 00 00 00 FC 00 00 80 FF FF 1F 00 E0 07 00 F0 03 00 F8 01 F8 F1 FF 1F 00 00 F8 7F 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F8 01 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F8 01 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F8 01 00 00 00 00 00 00 00 00 00 00 00 00 00

    2.2.8.11 MILCMD_DRAW_GLYPH_RUN
    Q7. How is the foreground brush "hForegroundBrush" used to draw the glyph bitmaps?

    3.1.1.6.3 Drawing Text
    Q8. The documentation states "When it is time to render a glyph run, the composition engine calculates the scale at which it needs to be rendered and chooses from the realization list the font face that best matches that scale."  How does the composition engine calculate the scale at which the glyph run needs to be rendered?

    Thursday, January 17, 2013 11:46 AM

Answers

  • Edgar,

    Thanks for confirming the errors in the document.

    I am disappointed that my question about how to interpret the bitmap data was not answered (those sections you referred to in your last post do not contain any information on the bitmap format).  In the meantime I have tried to interpret the bitmap data as 1 bit per pixel but the result was a horribly mangled bitmap.  The best interpretation of the bitmap data that I can find is still the one I described in my first post (8 bits per pixel) but this is obviously wrong since the bitmap is 1065 pixels wide which is not a multiple of 8!

    I will do as you suggest - create new threads on this forum for further questions and try to get help at dochelp@microsoft.com.

    Thanks anyway.

    Mark
    • Marked as answer by Mark Magro Friday, March 08, 2013 11:25 AM
    Friday, March 08, 2013 11:24 AM
  • Mark,

    The bitmap is composed as 1-bit-per-pixel. As the document mentions, the bitmap is made of 1-bit elements.

    Can you contact me at dochelp at microsoft dot com? Please mention this thread and address the email to my attention. I'd like to further understand your interpretation and investigate whether there is any clarity issue.

    Thanks,

    Edgar

    Friday, March 08, 2013 8:45 PM
    Moderator
  • Mark,

    The way to interpret your bitmap data is as follows:

    width: 1065 (in bitmap elements)

    height: 15  (in bitmap elements)

    stride:136 (number of bytes per row)

    Number of bits per pixel = 1

    width (in bitmap elements): 1065 Rounded to 32 bit boundary = 1088

    stride = Number of bytes per row = 1088 / 8 = 136

    The length of the bitmapElements field is x bytes, where x = stride * height = 2040

     

    Hope this helps,

    Edgar

    Thursday, April 04, 2013 6:28 PM
    Moderator

All replies

  • Hi,

    I will review this and follow-up.

    Thanks,

    Edgar

    Thursday, January 17, 2013 5:07 PM
    Moderator
  • Hi,

    Any news?  I have not got any replies to my questions yet.

    Thursday, January 31, 2013 8:30 AM
  • Hi Mark,

    I will update you as soon as we have the answers.

    Thanks,

    Edgar

    Thursday, January 31, 2013 9:07 PM
    Moderator
  • Q1 Answer.

    The algorithm for thickening or thinning the glyphs is itself not part of the protocol. The overall idea of the algorithm is that it uses the PreconstrastLevel value (1 through 6) to thicken the bitmap of the glyph.

    Monday, February 11, 2013 6:01 PM
    Moderator
  • Q2 Answer.

    You observation is correct. Only the least significant 16 bits are relevant for GlyphIndices. We will clarify that in a future release of the document.

    Monday, February 11, 2013 6:03 PM
    Moderator
  • Q7 Answer.

    hForegroundBrush is a brush resource used to draw the glyph run as the foreground brush. i.e. the brush used to draw the glyphs themselves.

    Brush resource message processing is defined in the following sections for each specific resource of type TYPE_SOLIDCOLORBRUSH, TYPE_LINEARGRADIENTBRUSH or TYPE_IMAGEBRUSH:

    3.3.5.10   Processing Brush Resource Messages

    3.3.5.10.1   MILCMD_SOLIDCOLORBRUSH

    3.3.5.10.2   MILCMD_LINEARGRADIENTBRUSH

    3.3.5.10.3   MILCMD_IMAGEBRUSH
    Monday, February 11, 2013 6:03 PM
    Moderator
  • Q3 and Q4 Answers.

    As documented in Section 2.2.7.75 MILCMD_GLYPHBITMAP

    horOriginX:

    The offset along the X-coordinate that is applied (added) to the glyph anchor point to get the coordinate of the left edge of rectangle where the glyph should be placed. This value works for regular text and is irrelevant for sideway text. Measured in bitmap texels.

    horOriginY:

    The offset along the Y-coordinate that is applied (subtracted) from the glyph anchor point to get the coordinate of the top edge of rectangle where the glyph should be placed. This value works for regular text and is irrelevant for sideway text. Measured in bitmap texels.

    horAdvance:

    The offset along the X-coordinate that is subtracted from the glyph position when the text is right-to-left. Measured in bitmap texels.

    verOriginX:

    The offset along the X-coordinate that is applied (added) to the glyph anchor point to get the coordinate of left edge of rectangle where the glyph should be placed. This value works for sideway text and is irrelevant for regular text. Measured in bitmap texels.

    verOriginY:

    The offset along the Y-coordinate that is applied (added) to the glyph anchor point to get the coordinate of top edge of rectangle where the glyph should be placed. This value works for sideway text and is irrelevant for regular                    text. Measured in bitmap texels.

    Width:

    Bitmap width, measured in bitmap texels.

    Height:

    Bitmap height, measured in bitmap texels.


    Thursday, February 14, 2013 9:24 PM
    Moderator
  • Q6 Answer.

    Stride is defined as UInt32 so it is aligned to 32bit boundaries.

    Thursday, February 14, 2013 9:29 PM
    Moderator
  • Q8 Answer.
    This is implementation-specific to the composotion engine and is not related to the protocol on the wire.
    A compositor implementation is free to use the data received over the wire in different ways, for example, applying a custom scaling factor, transformation etc. on the text.
    A future release of the document will reflect that clarification.


    Friday, February 15, 2013 9:05 PM
    Moderator
  • Q5 Answer.

    A future release of the document will clarify that bitmapElements is an abstraction used in explaining how an array of bitmap glyphs get added to a glyph cache via the MILCMD_GLYPHCACHE_ADDBITMAPS command that it issues on a GlyphCache resource.

    2.2.3.6   MilGlyphBitmap

    2.2.7.63   MILCMD_GLYPHCACHE_ADDBITMAPS

    2.2.7.75   MILCMD_GLYPHBITMAP

    3.2.5.6.1   MILCMD_GLYPHCACHE_ADDBITMAPS

    The server MAY add glyph bitmaps to the glyph cache by sending this message for the targeted glyph cache. For details on message fields and usage, see sections 2.2.7.63 and 3.1.1.6. The glyph bitmaps included in the command's payload have MILCMD_GLYPHBITMAP headers followed by the glyph pixels (section 2.2.7.75).

    3.3.5.6.1   MILCMD_GLYPHCACHE_ADDBITMAPS

    The client MUST process this message by adding the message glyph bitmaps to the targeted glyph cache resource. For details on message fields and usage, see sections 2.2.7.63 and 3.1.1.6. The glyph bitmaps payloaded by the command have MILCMD_GLYPHBITMAP headers followed by the glyph pixels (2.2.7.75).

    Thanks,

    Edgar
    Wednesday, February 20, 2013 8:14 PM
    Moderator
  • Regarding Q3, Q4, Q5 and Q6.

    Very interestingly, when parsing the MILCMD_GLYPHBITMAP header (section 2.2.7.75), if I take the total size of the three reserved fields to be 8 bytes instead of 12 bytes, the values of all the other fields suddenly make sense!  The "width" and "height" fields no longer seem swapped.  Similarly, the "horOriginX" and "horOriginY" fields no longer seem swapped.  The "stride" field now has a correct value (previously it was zero).  Also, even in my flawed interpretation of the bitmap data, the first character of the text contained in the bitmap now appears in its correct position.

    Therefore it seems there is a documentation error in section 2.2.7.75.  The total size of the reserved fields should only be 8 bytes.  Also note that in the documentation of MilGlyphBitmap (section 2.2.3.6) the length of the glyph bitmap data is specified to be "stride * height / 8".  It should be "stride * height".  Can you confirm that these are documentation errors please?

    My question on how to interpret the bitmap data has not been answered.  Can you clarify this please?  In other words, referring to the protocol data in Q6 again, if I had to give you that 2040-byte chunk of data and tell you that the width is 1065 bits, the height is 15 rows and the stride is 136 bytes, how would you generate a bitmap out of this information?

    Thursday, February 21, 2013 10:45 AM
  • Mark,

    I will have a look and follow-up with the answers.

    Thanks,

    Edgar

    Thursday, February 21, 2013 3:59 PM
    Moderator
  • Mark,

    Your observation is correct. The length of each BitmapElements field (section 2.2.3.6) is x bytes, where x = stride * height. This change will be reflected in a future release of the document.

    The bitmap height is measured in pixels. The stride is the number of bytes to store one pixel row.

    Let me know whether this helps.

    Thanks,

    Edgar
    Tuesday, February 26, 2013 7:50 PM
    Moderator
  • Mark,

    We confirm that the total size of the reserved fields should be 8 bytes instead of 12 bytes. The changes will appear in a future release of the document.

    2.2.7.75   MILCMD_GLYPHBITMAP

    reserved0 (4 bytes):  Can be set to any value when sent, and MUST be ignored when received.

    reserved1 (4 bytes):  Can be set to any value when sent, and MUST be ignored when received.

    Thanks,

    Edgar


    Monday, March 04, 2013 10:32 PM
    Moderator
  • Mark,

    the client processes the bitmaps as documented in 3.3.5.6.1 MILCMD_GLYPHCACHE_ADDBITMAPS
    the drawing of the glyph run is described in 3.1.1.6   Drawing Text

    I am posting this message as an explicit closure to this thread.

    If you have further questions, please feel free to start a new thread on this forum or send the question to dochelp at microsoft dot com

    Thanks,
    Edgar

    Wednesday, March 06, 2013 8:56 PM
    Moderator
  • Edgar,

    Thanks for confirming the errors in the document.

    I am disappointed that my question about how to interpret the bitmap data was not answered (those sections you referred to in your last post do not contain any information on the bitmap format).  In the meantime I have tried to interpret the bitmap data as 1 bit per pixel but the result was a horribly mangled bitmap.  The best interpretation of the bitmap data that I can find is still the one I described in my first post (8 bits per pixel) but this is obviously wrong since the bitmap is 1065 pixels wide which is not a multiple of 8!

    I will do as you suggest - create new threads on this forum for further questions and try to get help at dochelp@microsoft.com.

    Thanks anyway.

    Mark
    • Marked as answer by Mark Magro Friday, March 08, 2013 11:25 AM
    Friday, March 08, 2013 11:24 AM
  • Mark,

    The bitmap is composed as 1-bit-per-pixel. As the document mentions, the bitmap is made of 1-bit elements.

    Can you contact me at dochelp at microsoft dot com? Please mention this thread and address the email to my attention. I'd like to further understand your interpretation and investigate whether there is any clarity issue.

    Thanks,

    Edgar

    Friday, March 08, 2013 8:45 PM
    Moderator
  • Mark,

    The way to interpret your bitmap data is as follows:

    width: 1065 (in bitmap elements)

    height: 15  (in bitmap elements)

    stride:136 (number of bytes per row)

    Number of bits per pixel = 1

    width (in bitmap elements): 1065 Rounded to 32 bit boundary = 1088

    stride = Number of bytes per row = 1088 / 8 = 136

    The length of the bitmapElements field is x bytes, where x = stride * height = 2040

     

    Hope this helps,

    Edgar

    Thursday, April 04, 2013 6:28 PM
    Moderator