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.
Merge ctors from (width, height) and (width, height, scale) into a
single one because the former really should be just a special case of
the latter for scale == 1 but, surprisingly and confusingly it wasn't,
because the latter also multiplied the size by scale, meaning that width
and height parameters had different meanings.
This resulted in at least 3 bugs when using scale factors different from
1: first, copying bitmaps wasn't done correctly because as
wxBitmapRefData copy ctor incorrectly scaled its size by scale again.
And second, creating bitmap from wxImage whose size wasn't divisible by
scale not just didn't work correctly but crashed when accessing memory
outside of the image because (unnecessarily) dividing and multiplying
the image size by scale wasn't idempotent. Finally, even for the images
of even size (assuming scale factor of 2), bitmaps created from them
used incorrect width and height, corresponding to the half of the image
dimensions, instead of the same ones, as they're supposed to be (the
scaled dimensions are supposed to be returned by GetScale{Width,Height}
methods).
Closes#17505.
wxBitmap should be made transparency-capable before copying wxIcon bits to it. Doing so when wxIcon bits are already copied seems to work fine for OSX 10.8, but not for newer versions.
Closes#17953.
To avoid collisions with boost and c++ standard library using the assert macros starting with two underscores is the default under these new SDKs. Since they already existed in our minimum deploment SDK we can switch them safely.
Cocoa has been the default toolkit in wxWidgets for a long time. There is really no good reason to use Carbon in 2016 and this removes a lot of unused and unmaintained code.
Homogenize the behaviour of all ports when creating bitmaps with 0 width or
height: just fail always as it doesn't seem to make sense to support this.
Closes#16828.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78434 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxBitmap uses CGImage instead of NSImage internally and the conversion
looses NSImage metadata. In particular, it looses the "template"
attribute, which is set for files ending with "Template" and loaded
trough wxArtProvider.
This change makes it easy to use template images with native controls
such as the toolbar.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78016 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
It is not only useless with any modern C++ compiler, but also deprecated
in C++11. Removing it fixes Clang warnings on the subject.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76580 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Make overriding virtual methods more explicit and enable additional checks
provided by C++11 compilers when "override" is used.
Closes#16100.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76173 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
