Complete changes of 5e7b08f9ea (Correct wxDC::GetContentScaleFactor()
documentation, 2023-04-13) to add the information about the version in
which the behaviour of this function changed, as it was already done in
the version of this commit cherry picked to 3.2 branch, i.e. 8094ed5795
(Correct wxDC::GetContentScaleFactor() documentation, 2023-04-13).
Closes#23748.
Document that it returns the same value as GetDPIScaleFactor() wxWindow
method and _not_ the wxWindow method with the same name.
This is very confusing, but there doesn't seem to be anything to be done
about it by now.
See #23441.
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 the same thing as bd92523bc5 (Fix use of Doxygen @addtogroup
command, 2022-08-03) except it fixes comments format for all the other
occurrences of "@{" and "@}" too, not just for those used with
@addtogroup which was the problem in #22572.
This fixes many different formatting problems due to attaching various
Doxygen commands to wrong elements because of broken grouping, e.g. all
overloaded functions were documented incorrectly and there were several
problems in wxString documentation.
See #22248.
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 function existed since a long time but somehow was never
documented.
Also minor improvements to the just added documentation of
wxDC::GetDPIScaleFactor().
Don't say that passing wxNullFont to it is allowed because it isn't
neither in wxGTK nor in wxOSX and also remove the part about destroying
the previous font because we hadn't had to destroy the fonts explicitly
since 25 years.
Still document that setting an invalid font works in wxMSW, but explain
that doing this is not a good idea.
DoDrawSpline() implementations for all ports work for the number of points
>= 2 (for 2 points there is drawn a straight line) so we need to add checks
whether this requirement is met.
See #19172.
This is the case for wxMSW implementation and while the other ones seem
to accept 1 or 2 points too, document the most stringent requirement,
especially because not satisfying it results not "just" in assertion
failure, but also in a crash in wxMSW.
This should obviously be improved further by, at the very least, using
wxCHECK and not wxASSERT in wxMSW code or, maybe, actually handling the
degenerate cases there if all the other ports really support them.
See #19172.
Current DeviceToLogical{X|Y}(), LogicalToDevice{X|Y}(),
DeviceToLogicalRel{X|Y}(), LogicalToDeviceRel{X|Y}() functions
don't take into account transformations applied with
SetTransformMatrix() so conversion results are invalid if coordinate
system is e.g. rotated.
We need to implement new conversion functions that take into account all
applied transformations and also convert x,y coordinates in one call
because in general case x,y coordinates are coupled and cannot be
converted independently on each other.
Closes#18923.
Use wxBRUSHSTYLE_SOLID/TRANSPARENT constants instead of wxPENSTYLE_XXX
ones, as even though they have the same values, using brush style for
the background makes more sense.
Also document that the default background mode is transparent.
This restores the previous behaviour inadvertently changed by bfeae1922d
(Minor optimizations in GetMultiLineTextExtent(), 2020-06-10) and makes
it official by documenting it and adding tests checking for it.
It wasn't completely obviously if this was intentional or accidental
before, but at least wxStaticText itself relied on the old behaviour,
and chances are that so did some code outside the library, so make this
part of the API now.
See #18825.
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.
Since OS X 10.12 it has been named macOS so it makes sense
to reference it in documentation as such, even when it
sometimes refers to older versions which were called (Mac) OS X.
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.
Determining whether there is an actual clipping region or not is not
that simple, as shown by the recent problems in wxDCClipper code, so
return a boolean value indicating this from GetClippingBox() directly,
instead of requiring the caller to find it out on their own.
This simplifies wxDCClipper code, as well as any other code calling
GetClippingBox(), at the price of some extra complexity in wxDCImpl
itself, which seems to be worth it.
In wxGCDCImpl::ComputeScaleAndOrigin() current affine transformation matrix (applied with SetTransformMatrix, ResetTransformMatrix) has to be concatenated with current basic transformations (applied with SetDeviceOrigin, SetLogicalScale, etc.).
Closes#17674.
Graphics renderers (exposed through wxGraphicsContext) support arbitrary affine transformations so it is possible to add support for affine transformations in wxGCDC by implementing all wxGCDC::*TransformMatrix() functions with calls to respective wxGraphicsContext functions.
Additionally, this implementation adds support for affine transformations in wxDC under wxGTK3 because in this port wxDC is equivalent to wxGCDC.
ID2D1RenderTarget::PushAxisAlignedClip/PopAxisAlignedClip used to clip the region (with wxGraphicsRenderer::Clip) and ID2D1RenderTarget::PushLayer/PopLayer used to rendering to the transparent layer (with wxGraphicsRenderer::BeginLayer) are non independent but have to be used in the controlled sequences: "A PushAxisAlignedClip and PopAxisAlignedClip pair can occur around or within a PushLayer and PopLayer, but cannot overlap" (and of course finally each Push* call must have a matching Pop* call).
To control the sequence of access to the AxisAlignedClips and Layers there is implemented a wxStack data member holding Clips/Layers parameters which reflects a physical stack of respective Clips/Layers in ID2D1RenderTarget. This way we know in which order to pop and what to pop from ID2D1RenderTarget stack if there is a need to do so.
Closes#17590
When there is no clipping region currently set then current effective clipping region is identical with entire DC surface and therefore DC size should be returned as a region size.
Closes#17013
While setting a clipping box there is necessary to intersect it either with current clipping region location if such region exists or with wxDC surface extents if no clipping region is set. This way effective clipping box will be always inside the wxDC surface.
Note: Effective clipping box can be an empty region.
See #17013
Apparently it's a common convention to allow width and/or height of a
rectangle to be negative as both GDI and Cairo handle this natively, so also
allow this for GDI+ and document this as the expected behaviour.
Closes#17495.
They are relatively important, especially the origin-related ones as
SetUserScale() can (should?) be used instead of SetLogicalScale(), but
SetLogicalOrigin() can be more convenient than SetDeviceOrigin(), so provide
at least skeletal documentation for them.
