Cairo colour patterns support only RGBA colours and therefore it is not
possible to create a colour pattern from wxPen with non-RGB colour
(non-solid colour). As a workaround under wxOSX for solid wxPen with
non-solid colour we can convert it to Cairo surface pattern (stiple)
because under wxOSX non-solid colour is actually represented by a pattern
image.
Cairo colour patterns support only RGBA colours and therefore it is not
possible to create a colour pattern from wxBrush with non-RGB colour
(non-solid colour). However under wxOSX, when we have a solid wxBrush with
non-solid colour, we can convert it to Cairo surface pattern (stiple)
because under wxOSX non-solid colour is actually represented by a pattern
image.
Don't scale, or even copy, the font object unnecessarily in the common
case when the font scaling factor is 1.0 anyhow.
No real changes, just make the code slightly more efficient and also a
bit more concise after the changes of the previous commit.
Respect the system font scaling parameter (e.g. "Fonts->Scaling Factor"
in Gnome Tweaks, "Force font DPI" in KDE System Settings or
GDK_DPI_SCALE environment variable) when drawing text using wxFont.
This ensures that generic widgets have their text scaled appropriately
to be consistent with native widgets.
Closes https://github.com/wxWidgets/wxWidgets/pull/1635
Under wxOSX bitmap pixel values are already premultiplied so bitmap data
can be copied to the target surface directly.
Since 992b594c wxMask bitmap colours are no longer inverted and have
the same meaning as for another ports.
wxAlphaPixelData can be only used to access pixel data in 32 bpp bitmaps.
Also, because bitmaps can have both alpha values and mask, the mask should
be applied to the created surface even if alpha channel exists. Masked
pixels become fully transparent and unmasked pixels should retain original
alpha values.
Closes#18570.
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.
