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.
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.
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.
Current behavior of AddArcToPoint() when there is no current point is not
documented and moreover it is not the same in native macOS and in generic
implementation. Under macOS nothing is done and "no current point" error
is raised but under other ports (generic implementation) only arc
is drawn (without initial line).
When there is no current point, in similar functions AddCurveToPoint(),
AddQuadCurveToPoint() it is initially set to the some known control point
of the curve but this approach cannot be applied to AddArcToPoint().
The only well defined fallback point seems to be (0, 0) and this option
is implemented here.
See #18086.
AddArcToPoint() on macOS port is implemented with native API (CGPathAddArcToPoint) so its behaviour should be considered as a reference for generic implementation used in another ports.
Closes#18086.
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.
This is an implementation detail, don't confuse the user with this
template class which isn't supposed to be used in the user code.
Also improve the example in the documentation, the old one (using pen of
width 0 but with a colour) didn't make much sense.
Apparently, DirectWrite fonts can be created only from TrueType fonts and
therefore only such fonts can be used with Direct2D-based wxGraphicsContext.
When unsuported GDI font is passed to CreateFont() then no graphics font is
created and this unsuccessful attempt is signalled by returning
wxNullGraphicsFont. This null object can be used in e.g. wxGC::SetFont()
to check if font was actually created.
See #17790.
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.
1. Elements of resulting matrix are modified directly (in-place) in Matrix3x2F::SetProduct() so none of the multiplied matrices can be the instance of the resulting matrix.
2. The parameter matrix in wxGraphicsMatrixData::Concat() should be a multiplicand, not a multiplier.
See #17670.
Native ID2D1RenderTarget::SaveDrawingState method stores in ID2D1DrawingStateBlock only transform, antialiasing mode, text-rendering options and tags but not currently set ID2D1Layers (which are used in wxD2DContext for clipping purposes). Therefore current stack of layers has to be stored "manually" alongside ID2D1DrawingStateBlock in a dedicated data structure (LayerData) in PushState() and restored also "manually" in PopState().
Closes#17626.
Added section to group similar functions in the documentation of wxGraphicsContext.
Fixed references to the section describing wxPGProperty attributes.
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
For the sake of compatibility with Cairo (and Direct2D) an initial line segment should be added to the path from the current point (if set) to the beginning of the arc.
Closes#17557
To handle properly all combinations of the start and end angles and to ensure consistency with Cairo renderer behaviour there is necessary
1. To normalize angle values the same way as it is done in Cairo.
and
2. When difference between end angle and start angle >= 2*pi then in addition to the arc itself also one or more full circles have to be added to the path.
See #17558
See #17557
Because wxGraphicsPath comprises current ID2D1PathGeometry object and the collection of transformed (sub-)geometries (ID2D1TransformedGeometry objects) so to concatenate two paths we need to concatenate their current geometries as well as to combine the collections of transformed geometries.
Unfortunately, it seems that this is not a straightforward method to apply transformation to the current underlying path geometry (ID2D1PathGeometry object) "in-place" (ie. transform it and use for further graphics operations). Some simple methods offered by Direct2D are not useful for these purposes:
1. ID2D1Factory::CreateTransformedGeometry() converts ID2D1PathGeometry object to ID2D1TransformedGeometry object and ID2D1TransformedGeometry inherits from ID2D1Geometry (not from ID2D1PathGeometry) and cannot be used for path operations.
2. ID2D1Geometry::CombineWithGeometry() which could be used to get final geometry by combining empty geometry with transformed geometry doesn't offer any combine mode which would produce a "sum" of geometries (D2D1_COMBINE_MODE_UNION gives kind of outline). Moreover the result is stored in ID2D1SimplifiedGeometrySink not in ID2DGeometrySink.
So, it seems that ability to transform the wxGraphicsPath (even several times) and still use it after this operation(s) can be achieved by using a geometry group object (ID2D1GeometryGroup) this way:
1. After applying transformation to the current path geometry with ID2D1Factory::CreateTransformedGeometry() the result is stored in the collection of transformed geometries (an auxiliary array) and after that a new (empty) geometry is open (in the same state as just closed one) and this geometry is used as a current one for further graphics operations.
2. Above steps are done at every transformation so our effective geometry will be a superposition of all previously transformed geometries stored in the collection (array) and the current operational geometry.
3. If there is necessary to use this combined effective geometry in any operation then ID2D1GeometryGroup created with ID2D1Factory::CreateGeometryGroup() from the collection of stored geometries will act as a proxy geometry.
Closes#17549
Since resulting wxGraphicPath should have the same state as appended path so we have to grab in wxGraphicsPath::AddPath also auxiliary data from appended wxGraphicsPath.
See #17532
When current point is not set before the call to wxGraphicsPath::AddCurveToPoint() then it should be set at first control point prior to adding a curve (function should behave as if preceded by MoveToPoint).
See #17526
When sub-path is closed with CloseSubpath() then current point should be moved to the joined endpoint of the sub-path (what is equivalent of moving it to the starting point of the sub-path). To implement this behaviour we need to store on our own the starting point of the figure in a dedicate data member because native D2D renderer apparently doesn't offer any support for retrieving it.
See #17520
Circle/ellipse should be appended as a closed sub-path and the current point after the operation should be moved to "the rightmost point" of the figure ((x+r,y) and (x+w,y+h/2) respectively).
See #17520
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
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
