Make wxBitmapBundle compatible with bitmap scale factor > 1, both when
converting the latter to the former and when retrieving bitmaps from the
bundle.
See https://github.com/wxWidgets/wxWidgets/pull/2564
Use the scaled size, different from the default size, when constructing
wxBitmapBundle from an existing wxBitmap to keep the existing code using
scaled bitmaps working.
Add a unit test checking that this now works as expected under the
platforms where scale factor is used.
Bitmaps returned from this function must have the appropriate scale
factor, e.g. 2 in standard high DPI case, in order to be drawn at
correct size in the ports where logical pixels are different from the
physical ones, such as wxOSX and wxGTK3.
Notably, this allows wxGenericStaticBitmap to work correctly in high DPI
in these ports too.
This also allows to undo some of the changes done in 399b0ff9ae (Use
wxBitmapBundle instead of bitmap scale factor in wxGtkImage, 2021-10-16)
to wxGtkImage code and keep using the same code that had been used
before.
This will make it possible to change them later without breaking ABI,
which is probably worth paying the price of a function call (assuming
the compiler could de-virtualize this call and inline it before).
No real changes.
We need to be able to change the scale factor of the bitmaps returned by
wxBitmapBundle::GetBitmap(), so add a function allowing to do this.
Also add wxHAS_BITMAP_SCALE_FACTOR allowing to check whether this
function actually does something non-trivial and explain in the docs
that GetScaleFactor() always returns 1 on the platforms where this
symbol is not defined.
This is similar to 858248d055 (Fix declaration shadow warning in
wxHtmlHelpFrame, 2021-04-21) and fixes another -Wshadow from gcc 11 by
getting rid of the last parameter confusingly named as its type.
See #19153.
Normally non-toplevel windows must have non-null parents, as creating
them with null parent would fail, but our own wxTabFrame used in AUI is
an example of a window which can have null parent because it's actually
never created at all. This does look like a pretty bad hack, but it's
very unlikely to happen accidentally, so relax the assertion check added
in the previous commit to allow for it.
Using a wrong parent for the window managed by the sizer of the given
window or, alternatively, inserting a window into a wrong sizer, seems
to be a common mistake when creating sizer-based layouts and results in
hard to understand visual problems (as typically the window with the
mismatched parent/sizer just remains stuck at some wrong location).
So try to help detect it sooner and provide more information about the
problem by checking the parent of the window either when it is added to
the sizer -- if we already know which sizer the window is associated
with at that moment -- or when associating the sizer with the window
later.
Hide wxOSX implementation details by storing NSImage associated with the
bundle in a separate global map instead of making it part of
wxBitmapBundleImpl itself.
See https://github.com/wxWidgets/wxWidgets/pull/2555
This function was defined in wxGTK and wxOSX, but not in wxMSW or the
other ports, but it can be useful there too, so make it public and
define it in common code.
These resource files didn't appear in the .bkl ones and so were not used
at all and were not worth being used anyhow, as they didn't differ
significantly from sample.rc.
This is required for high resolution bitmaps support and it will be
needed in other samples too, so use it for all of them.
This probably will result in some problems due to remaining bugs with
high DPI support, but it should make them more noticeable and so should
help with finding and fixing them.
This warning was introduced by the recent 999340f288 (Check that
wxImageList::Create() is not called more than once, 2021-10-17), fix it
by using NULL for HIMAGELIST which is a pointer internally.
Closes#19298.
This avoids resizing the bitmaps in some common use cases and is similar
to the previous commit doing the same thing for wxButton.
Notice that this introduces a slight change of behaviour, as
AdjustToolBitmapSize() now can reduce, as well as increase, the size of
bitmaps used, which is necessary in order to shrink the bitmaps when
moving from a higher DPI resolution display to a lower-resolution one.
This is not 100% backwards-compatible, but should only have not very bad
cosmetic effects.
Avoid scaling the bitmaps by using the preferred size for them.
This results in significantly better appearance without any real
drawbacks in practice at 125% and 175% DPI scaling in the common case
when just a single and double-sized bitmaps are available, and still
seems to be acceptable at 150% scaling in this case.
Using bitmaps of preferred size avoids scaling and results in much
better appearance, so add methods allowing querying the bundle about the
bitmaps it supports and implement them in the various implementations.
This is not actually used anywhere yet, but will be soon.
Getting errors due to "missing" Nano SVG headers can be confusing, as
it's not immediately clear why are they missing, so try to make things
more explicit by using __has_include(), if available, to test for the
header before including it and giving a better error message if it
fails.
It still won't help people not using C++17 or those not reading error
messages, but should be better than nothing.
Unfortunately even using CallAfter() doesn't allow to completely repair
the toolbar display after moving it to a display with a different
fractional scaling, e.g. from 125% to 175%. There are still some minor
but visible display artefacts in this case that we can't get rid of even
by resizing the window containing the toolbar programmatically -- even
though doing it interactively does help.
Recreate wxImageList used for the bitmaps internally with the bitmaps of
the size corresponding to the new DPI.
This commit is best viewed with --color-moved git option.
Take wxBitmapBundle in wxButton::SetBitmapLabel() and related functions
in order to be able to associate several bitmaps to be used in different
resolutions with the button, instead of just a single bitmap.
Just return a null image instead, as this function can be called when we
don't have any bitmaps too -- as it happens in the Button::Bitmap unit
test, for example.
Nothing here, including the event table for this class using
non-existing wxBitmapButton::OnSysColourChanged (which is just the same
as wxWindow::OnSysColourChanged, in fact), was needed any longer ever
since the changes of a6fd73d33a (implement wxBitmapButton as just a
wrapper for wxButton under MSW, 2009-06-15), so simply remove all the
unused stuff.
Existing code may call functions taking wxBitmap with wxIcon, due to an
existing conversion from wxIcon to wxBitmap, so we need to provide a
similar conversion to wxBitmapBundle for compatibility.
This reverts commit 4e366b2cfb as it the
code removed by it is still needed and removing it results in unit test
failures in wxBitmapToggleButton unit tests with both GTK 2 and 3.
See https://github.com/wxWidgets/wxWidgets/pull/2548
