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.
The existing documentation was flat out wrong as it is simply impossible to
pass a circle through any two arbitrary points while also fixing its centre,
explain what this function really does and also use this as an opportunity to
point people to DrawEllipticArc() which is much less confusing.
Also clarify the segments drawing logic of DrawArc() as it is quite
counterintuitive too as it depends on the brush being used and is also
different from DrawEllipticArc() which uses a simpler logic.
See #15609.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75063 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxOSX uses wxGCDC for its wxDC functionality and wxGCDC doesn't implement this
operation, even not using the horribly inefficient wxGTK fallback.
See #15151.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74244 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't end the brief description at the first period if it's a period which is
part of "i.e." or "e.g.": escape the space following it to prevent Doxygen
from recognizing it as an end of sentence.
See #14866.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73084 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Unlike other similar classes, this one doesn't restore the previous clipping
region but just resets it because there is no way to get the current clipping
region from wxDC now. At least document this limitation until it can be fixed.
See #13834.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@71296 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
