gdiplus: Add some notes about the format of the data blob returned by GdipGetRegionData.

dlls/gdiplus/region.c

@@ -30,6 +30,43 @@
 
 WINE_DEFAULT_DEBUG_CHANNEL(gdiplus);
 
+/**********************************************************
+ *
+ * Data returned by GdipGetRegionData (for rectangle based regions)
+ * looks something like this:
+ *
+ * struct region_data_header
+ * {
+ *   DWORD size;     size in bytes of the data - 8.
+ *   DWORD magic1;   probably a checksum.
+ *   DWORD magic2;   always seems to be 0xdbc01001 - version?
+ *   DWORD num_ops;  number of combining ops * 2
+ * };
+ *
+ * Then follows a sequence of combining ops and RECTFs.
+ *
+ * Combining ops are just stored as their CombineMode value.
+ *
+ * Each RECTF is preceded by the DWORD 0x10000000.  An empty rect is
+ * stored as 0x10000002 (with no following RECTF) and an infinite rect
+ * is stored as 0x10000003 (again with no following RECTF).
+ *
+ * The combining ops are stored in the reverse order to the RECTFs and in the
+ * reverse order to which the region was constructed.
+ *
+ * When two or more complex regions (ie those with more than one rect)
+ * are combined, the combining op for the two regions comes first,
+ * then the combining ops for the rects in region 1, followed by the
+ * rects for region 1, then follows the combining ops for region 2 and
+ * finally region 2's rects.  Presumably you're supposed to use the
+ * 0x10000000 rect header to find the end of the op list (the count of
+ * the rects in each region is not stored).
+ *
+ * When a simple region (1 rect) is combined, it's treated as if a single rect
+ * is being combined.
+ *
+ */
+
 GpStatus WINGDIPAPI GdipCreateRegion(GpRegion **region)
 {
     FIXME("(%p): stub\n", region);