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.
Member data containing clipping box have to be updated not only when the clipping region is explicitly changed by SetClippingRegion()/DestroyClippingRegion() but also when existing wxGraphicsContext is associated with wxGCDC using SetGraphicsContext() or when wxGCDC coordinates are transformed with SetDeviceOrigin(), SetLogicalOrigin(), SetUserScale() or SetLogicalScale().
When any of these functions is called then clipping box data are marked as invalid and retrieved from underlying graphics context using wxGraphicsContext::GetClipBox() at nearest call to GetClippingBox().
See #17646.
If underlying graphics context is rotated then drawing a rectangle with origin at (0,0) doesn't cover all the drawing area. To draw over entire area we need to get extents of the actual clipping region (with applied all transformations) and use it as coordinates of the drawn rectangle.
See #17636.
Solution with full conversion from device to logical coordinates in wxGCDCImpl::DoSetDeviceClippingRegion doesn't seem to work under WXOSX (wxMacCoreGraphics) so we have to use for this port legacy implementation without full conversion of coordinates. Only offset of the origin is taken into account in this case (but not e.g. scale) but this should be enough for simple cases.
Closes#17609
Currently region given in device coordinates is decomposed into the stripes which are next transformed to the logical coordinates required by underlying wxGraphicsContext::Clip() function. Some of these stripes given in device coordinates can have 1-pixel height what after transformation to logical coordinates can give zero-height stripes (after rounding). This can lead to the situation that in the region transformed to logical coordinates some stripes can disappear and final transformed region shape is different from the source shape (it has gaps).
To fix this issue device coordinates of the region are not manually transformed to the logical coordinates but instead wxGraphicsContext's is temporarily set to the state where its logical coordinates are equivalent to device coordinates and thus clipping region can be applied directly.
Closes#17609
Because source wxRegion contains regions given in device coordinates and underlying wxGraphicsContext::Clip() function expects regions in logical coordinates so we have to convert device coordinates of all region components to source coordinates prior to calling this function.
Effective clipping box (always calculated in logical units) is the result of intersection of clipping box of the provided region with either clipping box of previously set clipping region (if set) or with wxGCDC surface extents if no clipping region is set. This way effective clipping box is always inside the wxGCDC surface.
Note: Effective clipping box can be an empty region.
See #17596
Graphics renderers accept negative clipping box size but for internal calculations done in wxDCImpl::DoSetClippingRegion() we need to have a box defined by (x,y) at top-left corner and having non-negative size so we need to recalculate parameters if necessary.
Ensure that 32bpp bitmaps selected in wxMemoryDC use DIB for their internal
representation as GDI+ functions don't seem to work correctly with DDBs.
Note: Code responsible for converting and fixing the bitmap has been moved
from wxGCDCImpl::wxGCDCImpl to wxGDIPlusRenderer::CreateContext because this
is the common entry point for creating context for GDI+.
Closes#17324.
Outlined rectangles are one pixel larger with vector-based drawing,
adjust them to get consistent behavior.
Ellipses do not appear to need adjustment.
See #17091
Update the bounding box in all the methods drawing something. This wasn't
done before in many of them, resulting in the bounding box remaining empty,
but it is updated now and a new test checking that it is was added.
Closes#12904.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76953 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Ensure that 32bpp bitmaps selected in wxMemoryDC use DIB for their internal
representation as GDI+ functions don't seem to work correctly with DDBs with
alpha channel.
Closes#13328.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75648 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Deprecate the use of the old untyped constants but don't schedule them from
removal in a future wx version by removing "#if WXWIN_COMPATIBILITY_3_0" tests
around their definition and use. Provoking deprecation warnings in the code
using these constants is worth it as they are unclear and it's easy to make
mistakes when using them, but breaking this code compilation outright can't be
justified -- even in the future.
Also use more informational wxDEPRECATED_MSG() instead of a simple
wxDEPRECATED() as it might not be obvious at all how should the code be
updated exactly.
Finally, avoid the use of deprecated constants inside the library itself.
As a side effect, this closes#15814.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75565 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Replacement of FUTURE_WXWIN_COMPATIBILITY_3_0 with WXWIN_COMPATIBILITY_3_0 in
r75532 resulted in tons of warnings as all code using wxSOLID and similar
constants now uses the deprecated methods taking int instead of the preferred
ones taking wx{Pen,Brush}Style (and similarly for wxFont{Style,Weight,Family}).
Fix all of them but this also would seem to mean that this change might not be
such a good idea at all.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75547 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
GetClippingBox() implementation relies on wxDCImpl::m_clip[XY][12] being
updated in DoSetClippingRegion() but this wasn't done here. Fix this by adding
the code to do this to the base class version of this method and calling it
from wxGtkPrinterDCImpl.
Also, refactor wxGCDCImpl to reuse the same code instead of duplicating it.
Closes#14697.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72674 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Maximum positive coordinate Cairo can handle is 2^23 - 1.
Also convert coordinates to logical so it works right with modified origin or scale.
See #14529
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72279 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Clearing a rectangle of size 32000 was not always enough to clear the entire
DC, so use INT_MAX instead -- this is the best we can do with the current
approach.
Closes#13445.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@71944 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Both GradientFillLinear() and GradientFillConcentric() changed the brush on
the underlying wxGraphicsContext but didn't restore the default brush back.
Closes#14131.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@71054 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
done for GDI+.
* Enable the use of the wxCairoContext on MSW.
* Enable creating a wxGCDC from an exisiting wxGraphicsContext.
* Since it's possible for a DLL that is using wx to not be on the PATH nor in
the same location as the .exe, change the wxDynamicLibrary::RawLoad method to
explicitly look first in the same place as the main wx-using binary. This way
it will find DLLs that are in the same folder as the wx-using binary even if
that would not be in the normal DLL search path.
* Change wxDCImpl and wxDC::GetLogicalScale to be const methods.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68935 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
