Re: [PATCH 1/1] gdiplus: Fix for the "graphics object has no HDC" issue in GdipDrawPath
On Tuesday, August 30, 2016 4:29:35 PM CEST Vincent Povirk wrote:
We really need an implementation that doesn't rely on gdi32.
Because of performance you mean? Because it seems like a lot of code duplication to me. Is it really necessary to differentiate between Software and GDI?
We really need an implementation that doesn't rely on gdi32.
Because of performance you mean? Because it seems like a lot of code duplication to me. Is it really necessary to differentiate between Software and GDI?
Not just because of performance. Gdiplus has some features that gdi32 does not, such as anti-aliasing, semi-transparent brushes, and gradient brushes.
On Tuesday, August 30, 2016 5:01:20 PM CEST you wrote:
Not just because of performance. Gdiplus has some features that gdi32 does not, such as anti-aliasing, semi-transparent brushes, and gradient brushes.
I see.. So basically everything with hdc is old GDI and everything without is GDI+?
Not just because of performance. Gdiplus has some features that gdi32 does not, such as anti-aliasing, semi-transparent brushes, and gradient brushes.
I see.. So basically everything with hdc is old GDI and everything without is GDI+?
If there's an HDC, we use a mix of GDI rendering and GDI+ rendering. If GDI can support a particular drawing operation, we use that. Otherwise, we render it internally and send it to the HDC using GdiAlphaBlend. At least, that's the general policy. There may be exceptions.
On Tuesday, August 30, 2016 6:25:11 PM CEST you wrote:
If there's an HDC, we use a mix of GDI rendering and GDI+ rendering. If GDI can support a particular drawing operation, we use that. Otherwise, we render it internally and send it to the HDC using GdiAlphaBlend.
At least, that's the general policy. There may be exceptions.
I see, thanks for clearing that up. Regarding the crash, in "SOFTWARE_GdipDrawThinPath" the line "GdipDeletePath(path);" seems faulty. It seems odd to delete "path", maybe it should be "flat_path" instead? Fabian Maurer
If there's an HDC, we use a mix of GDI rendering and GDI+ rendering. If GDI can support a particular drawing operation, we use that. Otherwise, we render it internally and send it to the HDC using GdiAlphaBlend.
At least, that's the general policy. There may be exceptions.
I see, thanks for clearing that up.
Regarding the crash, in "SOFTWARE_GdipDrawThinPath" the line "GdipDeletePath(path);" seems faulty. It seems odd to delete "path", maybe it should be "flat_path" instead?
Yes, you're right.
participants (2)
-
Fabian Maurer -
Vincent Povirk