For some reason one of the overloads of the c'tor left the m_qtPainter
field set to NULL rather than asking the wxDC for it's painter.
The rest of the class assumes the painter is not NULL.
Closes https://github.com/wxWidgets/wxWidgets/pull/1075
wxCairoContext::Flush was flushing back to the internal image but this
image wasn't drawn back to the QPainter until the wxCarioContext
instance was destroyed.
This fix ensure that after a call to Flush, anything drawn by Cario is
drawn back to the QImage.
Closes https://github.com/wxWidgets/wxWidgets/pull/1068
This method allows to retrieve the window this context is associated
with, if any.
Add "wxWindow*" argument to wxGraphicsContext ctor and provide the
window pointer to it when available, i.e. when creating the context from
a wxWindow directly or from wxWindowDC, which is also associated with a
window, in platform-specific code.
No real changes yet.
This is more consistent with the other headers, which are safe to
include even when the corresponding feature is turned off.
Also remove the now redundant wxUSE_ENH_METAFILE checks in the source
code including this header.
See https://github.com/wxWidgets/wxWidgets/pull/951
Graphics path is actually a line with null width so its bounding box
should be obtained with cairo_path_extents() function which assumes
that line width is 0.
Changes of c0b0562533 to common code broke
wxGTK1 build, as wx/gtk/private/wrapgtk.h is for wxGTK 2+ only.
Fix this by handling wxGTK 1 separately and including gtk/gtk.h directly
for it.
Hopefully this code will be removed, together with the rest of wxGTK1
support, in some not so distant future.
Add wx/gtk/private/wrapgtk.h wrapping gtk/gtk.h in pragmas disabling
these warnings and include it everywhere instead of directly including
gtk/gtk.h.
Also include wx/gtk/private/gtk2-compat.h from this wrapper header as it
was included by 90% of the files including gtk/gtk.h itself and it seems
to be better and simpler to just always include it.
Avoid using cairo_clip_extents() function, which was added in 1.4,
unless we have at least this version at both compile- and run-time.
This allows the library to be compiled under CentOS 5, which only has
Cairo 1.2 and which is, unfortunately, still in use.
Don't crash trying to use an uninitialized font in
GetPartialTextExtents() later if the font was created using
CreateFont(sizeInPixels, facename, flags) overload.
Closes#18021.
Returning true/false from wxCairoFontData::Apply() to indicate whether
Pango should or not be used was not very clear, so prefer to test for
the font explicitly in the code calling Apply() and make Apply() itself
void, consistently with the method with the same name in the other
classes.
Also avoid calling it at all from GetTextExtent() when using Pango, this
is completely unnecessary as the text colour doesn't have any bearing on
its extents.
Also use static_cast and const_cast as appropriate instead of C-style
casts.
It doesn't make much sense to require all the graphics backends to
create wxGraphicsPen from either wxPen or wxGraphicsPenInfo when the
former can be handled just once in the common code.
So do just this, leaving CreatePen() overload taking wxGraphicsPenInfo
where the real pen construction takes place and implementing
wxGraphicsPen creation from wxPen in the common wxGraphicsContext code.
This is not 100% backwards-compatible as any code inheriting from
wxGraphicsRenderer and overriding its CreatePen() will now be broken,
however this should be extremely rare (there is no good reason to
inherit from this class in the user code) and result in compile errors
if it does happen.
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.
