The changes of b20552116c (Allow wxBitmapBundle to specify its preferred
bitmap size, 2021-10-19) resulted in never rescaling the bitmaps in
standard size in high DPI at all, which isn't the right thing to do: by
default, i.e. if just a single bitmap is specified, we should scale it
up as necessary in order to show the UI elements in the correct sizes.
Define CopyFromIcon() directly in wxBitmapBase for the non-MSW ports, as
it was implemented exactly in the same way in all ports using this class
anyhow.
This means this function is not virtual any longer, but this shouldn't
be a problem as it was never supposed to be overridden in application
code and this couldn't be done with wxMSW, where it never was virtual in
the first place, anyhow.
No real changes, just a simplification.
Just use the same object, as wxIcon is the same thing as wxBitmap
anyhow, instead of re-creating another wxBitmap which can be subtly
different from the original one.
Notably, converting an icon with default scale factor of 1 to bitmap
when using a high DPI display resulted in a bitmap with the same
physical size but scale factor of 2, as wxOSXGetImageScaleFactor()
returned 2 in this case, i.e. changed the logical bitmap size.
This couldn't be anything other than a bug, so fix this and, at the same
time, simplify the code and make it consistent with the other ports.
We must call SetInitialSize() in Create() in order to take the size
argument passed to ctor/Create() into account -- it was completely
ignored previously.
But calling SetBitmap() must not change the initial size, as it can also
be done later, so just change the current size there instead (which is
consistent with wxMSW version and original behaviour, so keep it like
this, even though it's not totally clear if all ports do it).
Remove the now unused wxGenericStaticBitmap::GetBitmapSize().
Instead of defining them, slightly differently, in all the non-MSW
ports, define them once in wxStaticBitmapBase.
No real changes, this is just a simplification.
It's a handle, so make it a WXHANDLE rather than WXLPARAM and avoid
casting the handle when calling it (there is still a cast when calling
::SendMessage() inside this function, but this is unavoidable and this
cast was already there anyhow).
No real changes.
Use different members for storing wxBitmap and wxIcon instead of using a
single pointer for storing a heap-allocated copy of either of them
because this is simpler, more efficient due to avoiding unnecessary
conversions and RTTI, and will be simpler to generalize to using
wxBitmapBundle instead of wxBitmap in the upcoming commits.
As a side effect, don't assert in GetIcon() or GetBitmap() if there is
no valid icon or bitmap, as this is inconsistent with the other ports
and wasn't even consistent between these functions in wxMSW itself.
There should be no other changes in behaviour.
This function was used exactly once and it's simpler and more clear to
just inline it into Free() where it was called.
No real changes, this is just a small simplification.
For some reason, wxStaticBitmapBase methods were defined in the wrong
ctrlcmn.cpp file rather than statbmpcmn.cpp. Just move them there to
avoid confusion.
No real changes.
This commit is best viewed with --color-moved git option.
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.
