Legacy API cairo_win32_surface_create() can create only 24 bpp RGB surfaces but new API cairo_win32_surface_create_with_format() introduced in 1.15.4 supports creating also 32 bpp ARGB surfaces.
So, this new API can be used to create ARGB surface directly from ARGB bitmap (HDC), superseding current implementation based on the access to the bitmap data with cairo_image_surface_create_for_data().
Unfortunately, 0RGB bitmaps are not supported by cairo_win32_surface_create_with_format() and for such bitmaps surface has to be still created from bitmap data.
Add wxGraphicsContext::CreateFromNativeHDC() and wxGraphicsRenderer::
CreateContextFromNativeHDC() to allow creation not only from native
renderer object, but also from HDC, which is something universally
supported by win32 implementations.
When x- or y-coordinate of DC origin > 0 then surface created with cairo_win32_surface_create() is not fully operational (for some Cairo operations memory access violation errors occur - see Cairo bug 96482) so in this case we would need to apply a workaround and pass non-transformed DC to Cairo and next apply original DC transformation to the Cairo context operations on our own.
Closes#17564
There are straightforward ways to draw rectangles, circles and ellipses using native methods provided by Cairo renderer and they should be used instead of generic implementations.
See #17554
Reference count of the source Cairo context should be increased to prevent source context from being destroyed in wxGraphicsContex dtor (where cairo_destroy is invoked).
When wxGraphicsContext is created from wxPrinterDC then also logical scaling factor applied to the source wxPrinterDC has to be explicitly applied to the Cairo context.
All inherited transformation settings should be used only internally by wxGraphicsContext object and shouldn't be exposed through e.g. GetTransform() function and hence they are stored separately (in a dedicated variable) and "subtracted" from actual transformation settings for reporting purposes.
Closes#17496.
Modification of the mapping mode of underlying DC encapsulated in wxPrinterDC (from MM_ANISOTROPIC to MM_TEXT) which is done prior to creating Cairo context affects the value of device origin which needs to be applied to the Cairo context. Due to the change of the mapping mode it has to be rescaled based on the current scaling factor value.
See #17496.
When wxGraphicsContext is created from "native" Cairo context (cairo_t*) then transformation settings applied initially to the underlying source Cairo context need to be stored (in a dedicated variable) to make possible determining what transformations were applied to wxGC instance since its creation. Only these explicitly applied transformations are reported by GetTransform().
1. Because Cairo uses internally GetClipBox Win API to determine surface size so we can employ the same approach in wxGraphicsRenderer::CreateContextFromNativeContext and just call this API instead of executing complicated code to determine size of underlying objects selected into DC.
2. Determine context size (and initialize respective data members with proper values) for wxCairoContext created from wxWindow.
3. Initialize respective data members with 0 values for generic wxCairoContext (with no source object provided).
Since raw DC (encapsulated in source wxDC) can be modified in wxCairoContext explicitly (e.g. when context is instantiated from wxPrinterDC or wxEnhMetaFileDC) or implicitly (by some Cairo functions) we have to store its state in ctor and restore it in dtor to assure consistent state of the source wxDC.
Iterating over bit values with wxAlphaPixelData sets the internal wxBitmap's "has alpha" flag but we want to left it unchanged so we have to save its original value and restore it afterward.
Determine actual size of wxCairoContext created from native DC and HWND. This allows to report proper size of wxGraphicsContext created by wxGraphicsRenderer::CreateContextFromNativeContext / CreateContextFromNativeWindow.
When wxGraphicsContext is created from wxWindowDC or wxMemoryDC then transformation settings applied initially to the underlying source Cairo context need to be stored (in a dedicated variable) in order to have ability to determine what transformations were applied to wxGC instance since its creation. Only these explicitly applied transformations are reported by GetTransform().
Closes#17491.
When wxGraphicsContext is created from wxWindowDC then transformation settings already applied to the source wxWindowDC are not passed directly to the Cairo context through underlying GdkDrawable and therefore they need to be passed to the context explicitly.
These inherited transformation settings should be used only internally by wxGraphicsContext object and shouldn't be exposed through e.g. GetTransform() function and hence they are stored separately (in a dedicated variable) and "subtracted" from actual transformation settings for reporting purposes.
See #17491.
When wxGraphicsContext is created from wxMemoryDC then transformation settings applied to the source wxMemoryDC are not passed directly to the Cairo context through underlying GdkDrawable and therefore they need to be passed to the context explicitly.
These inherited transformations settings should be used only internally by wxGraphicsContext object and shouldn't be exposed through e.g. GetTransform() function and hence they are stored separately (in a dedicated variable) and "subtracted" from actual transformation settings for reporting purposes.
Closes#17482.
When wxGraphicsContext is created from wxMemoryDC with selected 32bppp wxBitmap then transformation settings applied to the source wxMemoryDC are not passed directly to the Cairo context through underlying HDC and therefore they need to be passed to the context explicitly.
These inherited transformations settings should be used only internally by wxGraphicsContext object and shouldn't be exposed through e.g. GetTransform() function and hence they are stored separately (in a dedicated variable) and "subtracted" from actual transformation settings for reporting purposes.
See #17482.
When Cairo surface is created from 32bpp wxBitmap then there is necessary to provide a location of its bit values to cairo_image_surface_create_for_data function and hence bitmap selected into wxMemoryDC has to be converted to DIB, if it is not a DIB already.
Moreover, if 32bpp bitmap doesn't contain real transparency data (is 0RGB bitmap) then its alpha values have to be corrected and set to wxALPHA_OPAQUE value (255).
Closes#17469.
cairo_surface_create_similar_image() introduced by the changes of
d6afb66388 is only available in 1.12 and later,
check for it being available and fall back to cairo_surface_create_similar()
with older versions.
This should fix Travis CI builds.
Fixed creating wxCairoBitmapData from 32bpp wxBitmap (with and without alpha channel). This also fixes wxCairoRenderer::CreateBitmap method.
1. 32bpp bitmap can represent under MSW either ARGB or RGB bitmap so there is necessary to examine its real contents with wxBitmap::HasAlpha function.
2. ARGB bitmaps are premultiplied and there is not necessary to premultiply them again.
Input void* parameter of wxCairoRenderer::CreateContextFromNativeContext can represent either DC handle or pointer to cairo_t object. It can be checked if it is a real HDC or not and proper wxCairoContext ctor can be invoked.
Closes#16991.
For a typical scale factor of 2, there won't be any odd-width lines,
and for any factor greater than 1.0, it won't be doing what was intended,
so just don't do it. See #17375
Don't use an uninitialized pointer in wxCairoContext ctor from wxPrinterDC in
wxGTK if retrieving Cairo context of the DC failed, set m_context to NULL in
this case (not sure if this is still not going to crash when used in
cairo_translate() below though).
