This ctor was previously present only in wxMSW, make it available in all
ports to allow the same code to compile everywhere.
In most of them wxDC argument is simply ignored, but in wxGTK and wxOSX
it is used to assign the appropriate scale factor for the new bitmap.
Enable previously wxMSW-only unit test checking for this.
The new name, recently introduced in 94716fd801 (Add
wxBitmap::CreateWithLogicalSize(), 2022-01-22), was perhaps more clear,
but also misleading and confusing because the postcondition
CreateWithLogicalSize(size, 2).GetLogicalSize() == size
was not satisfied under MSW, so rename it once again, and hopefully
finally, because the new name is consistent with GetDIPSize() returning
the same size.
Also try to improve the documentation a bit more.
Optimization of 2ae80673ff (Avoid unnecessarily unsharing bitmaps in
wxMSW, 2022-02-02) broke setting the scale factor because we didn't
update the right bitmap data in case bitmap hadn't had exclusive
ownership of its data before. Fix this by not using a reference which
may refer to another object after AllocExclusive() call.
Also change the other ports to unshared the bitmap when modifying its
scale factor so that the new unit test passes for them too.
The new function has a more clear name than CreateScaled() it replaces
and uses a more useful parameter order, with the scale factor, which
must always be specified when using it, coming before, and not after,
the depth, which almost never needs to be specified and so can be left
at its default value in 99% of cases.
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 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.
Just return NULL from this (wxOSX private, in spite of not using a
port-specific prefix) method.
This fixes crash in wxButton::SetBitmapXXX(wxNullBitmap), as shown by
the new test case which used to crash but doesn't do it any longer.
Closes#19257.
For internal purposes wxBitmap with mask should be converted to CGImage
with alpha values only (with no mask). This is i.a. needed to assure
compatibility of wxGraphicsBitmap format with other ports where these
bitmaps are in pure ARGB format.
wxImage with mask should be converted to wxBitmap with mask and not to
wxBitmap with alpha channel values. Converting wxImage mask to wxBitmap
alpha is not implemented under wxMSW and wxGTK and wxOSX implementation
should adhere to this convention.
This macro replaces the deprecated __Verify_noErr defined in the SDK.
It is different from assert, as the expression given to the macro is
always evaluated and then, if the result is not zero, and asserts are
on, an assert containing a human readable message with the description
of the error code is triggered.
Closes https://github.com/wxWidgets/wxWidgets/pull/1973
Co-authored-by: Vadim Zeitlin <vadim@wxwidgets.org>
After some recent changes bitmaps and icons with the type
wxBITMAP_TYPE_ICON could no longer be loaded. This implements a handler
for this (macOS only) bitmap type like the handler for
wxBITMAP_TYPE_ICON_RESOURCE.
Obtaining bytes per row makes sense only for bitmap image representation
so we have to ensure that the bitmap represenation exists before querying
for its row stride length. NSImage per se cannot provide this information.
Closes#18606.
In order to get access to wxBitmap's pixel data we actually have to work
with CGBitmapContext data and this context is created from NSImage by call
to wxBitmapRefData::EnsureBitmapExists() when we prepare to get access
to the data in wxBitmapRefData::GetRawAccess().
So, when we finish updating bitmap data we should update original NSImage
with actual CGBitmapContext data in wxBitmapRefData::EndRawAccess().
See #18606.
Checking whether alpha info flag contains one of
the constants representing image/bitmap with alpha
channel is done more than once in the code so this
check can be moved to a dedicated function.
Since wxBitmap can have both alpha channel values and mask we have to use
alpha channel (if required) in the sub-bitmap even if the mask is provided
too.
See #18513.
In the function wxMask::OSXCreate() to create a mask image, data copying
from the supplied memory buffer was not actually implemented and therefore
created mask was invalid.
Closes#18513.
For wxImage having both mask and alpha channel (it is technically possible), mask cannot be converted to alpha values and in this case resulting wxBitmap will also have both mask and alpha channel.
Since we always convert wxImage to 32 bpp wxBitmap, there is no reason to keep a separate mask for wxBitmap because alpha channel can be used directly.
Monochrome mask bitmap should have white pixels in the unmasked area and black pixels in the masked area, quite the opposite to what is implemented now.
Closes#10098.
When bitmap data are accessed with wxNativePixelData, which is designed
to handle RGB bitmaps, Alpha() function cannot be used because in this
case alpha component index is set to the default value -1 and actually
the blue component of the "preceding" pixel is accessed.
Closes#18478.
Defining a Mac-specific Create(wxMemoryBuffer) overload hid the other
Create() overloads, which are actually part of the public API, so they
couldn't be used any longer since the changes of
e7d21f6638
Fix this by renaming this Create() to OSXCreate(), to avoid hiding the
base class methods.
Also remove Mac-specific ctor taking wxMemoryBuffer, this is confusing
and can be avoided by just calling OSXCreate() directly in the only
place where it is used.
