Instead of implementing MSW-specific code to handle HDC for GDI+ context
directly in wxGCDC delegate acquiring/releasing HDC to underlying
wxGraphicsContext. Decoupling GDI+-specific code from wxGCDC will allow
us to implement handling HDC in other graphics renderers in a clean way.
Emulate a 1-pixel pen width as closely as possible.
This reverts:
334cf1cc91 (Take HiDPI scale into account for wxGCDC 0-width pen, 2021-04-03)
0d80050057 (Make wxGCDC behavior with 0-width wxPen consistent with MSW wxDC, 2021-03-02)
See #19077, #19115
If source wxImage has a mask we need to create ARGB32 Cairo surface (even
for RGB image) and based on the mask values set the alpha values to fully
transparent or retain original values.
Remove support for Borland C++ compiler, it wasn't tested since a long
time and probably didn't work anyhow and there was no interest in
keeping support for it since many years.
See https://github.com/wxWidgets/wxWidgets/pull/2087
This seems more logical and is compatible with wxDC in wxMSW and wxGTK2,
as well as other kinds of DC, e.g. wxPostScriptDC.
It also looks like the current behaviour was unintentional as it
happened only because wxGCDCImpl::DoGetTextExtent() always passed all
non-null parameters to wxGraphicsContext::GetTextExtent(), even if it
didn't need the values for all of them, and thus bypassed the special
case for the empty string which was already present in the latter
function.
Fix this, making DoGetTextExtent() more efficient as a side effect (we
now avoid unnecessary calls to pango_layout_iter_get_baseline() in the
most common case), and also add another test for empty string to
wxGraphicsContext itself, for non-GTK case.
Also document this behaviour and add a test checking for it.
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.
