Polygon fill modes in GDI and GDI+

gdi+winapi

The system default polygon fill mode in current device context is ALTERNATE (as I've learned from the Petzold book on Windows programming) and this one is used in Polygon Win32 function unless you change the mode with SetPolyFillMode.

My question is:
Does the GDI+ Graphics::FillPolygon (without the FillMode parameter in its signature) method also use the current device context fill mode or sets the well-known-default and then sets back the mode set before it was called?

Thanks!

Best Answer

I don't know the answer off the top of my head, but you could try finding out by retrieving the fill mode before and after the call. If it's not different, it's either not been changed, or was changed then changed back.

Related Solutions

C++ – GDI+ Dithering Problem

Hmm... The filling capabilities are determined by the target device. When working over remote desktop, AFAIK Windows substitutes the display driver, so that can change the supported features of the display.

when drawing on wm_paint, you actually draw directly on the screen surface, while .net usually uses double buffering (draws to in memory bitmap and then blits the entire bitmap)
there are some settings in gdi+ that affect the drawing quality. maybe there are different defaults for on-screen, off-screen and remote painting?

C# – A generic error occurred in GDI+, JPEG Image to MemoryStream

OK I seem to have found the cause just by sheer luck and its nothing wrong with that particular method, it's further back up the call stack.

Earlier I resize the image and as part of that method I return the resized object as follows. I have inserted two calls to the above method and a direct save to a file.

// At this point the new bitmap has no MimeType
// Need to output to memory stream
using (var m = new MemoryStream())
{
       dst.Save(m, format);

       var img = Image.FromStream(m);

       //TEST
       img.Save("C:\\test.jpg");
       var bytes = PhotoEditor.ConvertImageToByteArray(img);


       return img;
 }

It appears that the memory stream that the object was created on has to be open at the time the object is saved. I am not sure why this is. Is anyone able to enlighten me and how I can get around this.

I only return from a stream because after using the resize code similar to this the destination file has an unknown mime type (img.RawFormat.Guid) and Id like the Mime type to be correct on all image objects as it makes it hard write generic handling code otherwise.

EDIT

This didn't come up in my initial search but here's the answer from Jon Skeet

Best Answer

Related Solutions

C++ – GDI+ Dithering Problem

C# – A generic error occurred in GDI+, JPEG Image to MemoryStream

Related Topic