Replace user-specified empty constructors and destructors with the
compiler-generated versions, which has a number of advantages for code
generation, in addition to being more clear.
Closes#22965.
Closes#24058.
Having this line is not useful at all as it doesn't contain any
information and shouldn't be filled in the future as git-shortlog can
provide the information about people who changed the given file more
more reliably than consulting the comments in any case.
Keep the non-blank lines for historical purposes.
This is a combination of running clang-tidy with modernize-use-nullptr
check for some ports (GTK, X11, OSX) and manual changes to the ports for
which it couldn't be used easily (MSW, DFB) and also manually updating
the docs.
Also replace NULL with null or nullptr in the comments as this is more
consistent with the use of nullptr in the code and makes it simpler to
grep for the remaining occurrences of NULL itself.
And also use null in the assert messages.
Only a few occurrences of "NULL" are still left in non-C files, mostly
corresponding to unclear comments or string output which it might not be
safe to change.
This is implemented in Cairo and CoreGraphics renderers only, but this
is still useful as these renderers are used on the platforms where wxDC
wxINVERT logical function is not supported and this composition mode can
partially replace it.
This reverts most of the changes from ee2b02614e (Add GetDPIScaleFactor to wxDC
and wxGraphicsContext, 2022-04-16).
This is not supposed to be used to scale pixels, FromDIP will be added instead.
Temporary use scale=1 in the drawing sample until FromDIP is added.
It can be used to scale coordinates and sizes to make them DPI aware.
In the common headers, use wxDisplay::GetStdPPIValue() as default DPI value,
so the correct values are used on Windows (96) and macOS (72).
In wxMemoryDC use m_contentScaleFactor as the DPIScaleFactor, see e4c2298e5e
(Use window scale factor for all MSW wxDCs associated with windows, 2022-04-04).
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
Due to what looks like a bug, gcc 9.3.0 gives the following incomplete
error message without it:
include/wx/graphics.h:278:7: error: but
‘wxGraphicsGradientStop::wxGraphicsGradientStop(wxGraphicsGradientStop&&)’
does not throw; perhaps it should be declared ‘noexcept’
[-Werror=noexcept]
(without any other diagnostics).
Apply the utility from https://github.com/codespell-project/codespell/
to fix spelling issues in the headers under both include and interface
directories and add a file with a couple of exceptions.
The exact command line used was:
$ codespell -w -I misc/scripts/codespell.ignore -i 3 in*
It seems wrong to have this function in wxGraphicsContext only and not
in wxGraphicsRenderer, as this makes it impossible to create a context
associated with a non-default renderer while it doesn't cost us anything
to allow doing this.
No real changes, just clean up sources by removing trailing spaces from
all the non-generated files.
This should hopefully avoid future commits mixing significant changes
with insignificant whitespace ones.
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 a helper method used only in wxWidgets itself and only once, so
just inline it at the point of use to avoid exporting an unnecessary
function in the public API.
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.
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.
A convenience helper for writing generic code that may operate on
different kinds of DCs, all supported by wxGraphicsContext, but without
knowing its specific type.
Allow the code to determine which underlying technology is used for
implementing wxGraphics API. This is needed by the unit tests to account for
the known differences between platforms and may be useful in other cases.
Closes#16154.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76380 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
