Some cleanup in wxDC code: remove unnecessary casts, use RAII helpers
instead of manual memory and other resources management.
No real changes.
See #22378.
Update similar code in all ports to use wxScopedArray for arrays of
points, dashes etc in various wxDC implementations instead of using
new[] and delete[] manually.
No real changes, just make the code safer and shorter.
No real changes, just make the code updating the bounding box slightly
shorter by providing convenient and slightly higher-level overloads.
For now these functions are only in wxDCImpl, it's not clear if we
really need them in wxDC, so don't add them to the public API.
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).
Replace old functions with the new ones in the library code itself.
Note that wxSTC and wxRichText still use GetScaledXXX(), but they're
different functions that might need to be renamed/dealt with separately.
Change wxGCDCImpl::DoGetTextExtent() from rounding to the nearest
integer to rounding up: if e.g. height is 15.3 then 16 pixels should be
used for height, and not 15. Rounding was previously improved from
casting (which appears to be the initial code) in 0417955ddb (adding
correct filling area to arc, correct rounding and clipping, 2007-10-21).
Issues with nearest rounding became more visible after off-by-one fixes
for wxDC::DrawLabel() with wxALIGN_RIGHT and wxALIGN_BOTTOM positioning.
When using e.g. wxALIGN_RIGHT with a width of 72.4 the text could now be
drawn beyond the extent on the right because the text is not offset by
one to the left any longer.
We shouldn't call wxDCImpl::DoGetClippingRect() from
wxGCDCImpl::DoGetClippingRect() because it wouldn't return the correct
result if there is an affine transformation applied to this DC,
as wxDCImpl is not aware of such transformations.
We need to take into account all aplied transformations (including affine
transformations set with SetTransformMatrix()) while resetting clipping
box to its initial size.
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.
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
Drawing a circular point into a square pixel does not completely fill the pixel
with the new color, resulting in an alpha-blended appearance. Instead, draw a
square into the pixel. As a bonus, this is much faster, at least with Cairo.
See #19037
Remove support for Borland C++ compiler, it wasn't tested since a long
time and probably didn't work anyhow and there was no interest in
keeping support for it since many years.
See https://github.com/wxWidgets/wxWidgets/pull/2087
Generic wxDC::DeviceToLogicalRel{X|Y}() and wxDC::LogicalToDeviceRel{X|Y}()
functions don't take into account scaling applied with
wxDC::SetTransformMatrix().
We need to implement in wxDCImpl and its platform-specific derivates
new conversion functions that take all applied transformations into account.
See #18923.
Generic wxDC::DeviceToLogical{X|Y}() and wxDC::LogicalToDevice{X|Y}()
functions don't take into account transformations applied with
wxDC::SetTransformMatrix() so conversion results are invalid if wxDC is
transformed with both e.g. wxDC::SetUserScale() and
wxDC::SetTransformMatrix().
We need to implement functions in wxDCImpl and its platform-specific
derivates to do this conversion with taking into account all applied
transformations.
See #18916.
wxGCDC is often used from wxEVT_PAINT handler and showing an assert
dialog from any of its methods results in wxEVT_PAINT being generated
again, resulting in another assert and abort, which is not useful, so
remove this assert to at least avoid crashes whenever unsupported
logical function is used, as it happens e.g. in the "Mask Screen" of our
own drawing sample.
The compiler is smart enough to determine that the variables are always
initialized when they're actually used when using optimizations, but
gives a bunch of C4701 warnings for them if we don't initialize them in
the non-optimized debug builds.
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.
It is said in the wxDC::DrawText() documentation that current logical function is ignored by this function (e928566f). This should apply also to wxGCDC implementation for the sake of consistency and text drawing should be always done with wxCOPY mode regardless of the current mode set.
Fix regression in wxDC::Clear() and make wxGCDC::Clear() consistent with
it by using white if the background brush hadn't been explicitly set.
See https://github.com/wxWidgets/wxWidgets/pull/1582
The changes of ae2cb7d347 resulted in
transformation matrix not being initialized correctly any more.
Fix this by adding yet another helper, DoInitContext(), called both when
initializing wxGCDC using an existing wxGraphicsContext in the
corresponding ctor and the just created one in the other ones.
Closes#18429.
When creating wxGCDC from an existing wxGraphicsContext, it is better to
keep using the attributes (such as font, pen, brush) already configured
for it rather than overwriting them with the default values, which is
not very useful, unlike the new behaviour, which allows to configure
wxGraphicsContext using features not supported by wxDC API (e.g. alpha
channel for pens/brushes) and then use it via wxDC API only (allowing
the existing legacy code to use alpha, for example).
Avoid creating a default wxGraphicsContext unnecessarily, only to
immediately delete it and replace it with the provided one.
This was at best unnecessary and at worst resulted in a crash if the
default context couldn't be created, as happened on a headless system
(where wxImage-based wxGraphicsContext can still be created
successfully).
If nothing else, this avoids 2 calls to each of wxGetDisplaySize() and
wxGetDisplaySizeMM() on each and every wxGCDC construction which are
completely unnecessary as wxGCDCImpl uses its own hardcoded resolution
of 72 DPI, as do some other classes deriving from wxDCImpl.
And even for the classes which do compute these fields using the display
resolution, it may still be unnecessary to do it as they can be never
used if neither GetSizeMM() nor SetLogicalScale() are called on the
corresponding wxDC object.
Finally, this is more than an optimization as when using Cairo-based
wxGCDC without display (which is explicitly supported), calling
wxGetDisplaySize() simply doesn't work at all.
The new method returns a boolean flag which indicates whether there is
any clipping region or not and so is preferable to using the old one and
checking its return value to determine this, which can't be done
reliably.
No real changes, just call wxDCImpl::DestroyClippingRegion() from
the overridden versions in the derived classes instead of calling
ResetClipping(): this makes the code more clear as it follows the usual
pattern of the derived class doing something first and then forwarding
to the base class.
Also, as ResetClipping() is not really useful, add a comment documenting
that it shouldn't be used in the new code.
