This reverts commit b6d305e4f2 because
silently discarding images using a different scale factor is simply too
user-unfriendly: this can silently break the existing code, i.e. it can
still compile perfectly and not give any errors during run-time but not
show any images neither.
Also revert most of dc43d15cf7 (Add tests of storing HiDPI images in
generic wxImageList (wxOSX, wxGTK3), 2021-04-05) as these tests don't
pass any longer because the behaviour was intentionally changed.
See #22189.
The default size of the bitmaps created from bitmap bundles returned by
the Tango art provider for the client strings different from wxART_MENU
and wxART_BUTTON was changed from 24x24 to 16x16 in 766fefeb34 (Use SVG
instead of PNGs in tango art provider, 2022-01-27), see #22067, without
any real need and perhaps even non intentionally at all.
Restore the old default size to restore the old behaviour.
See #22189.
Don't always return success from this function, NanoSVG just skips
everything until the start of the XML prologue and doesn't return an
error even if it doesn't find it at all, so check that it could parse at
least something to avoid returning a "valid" bundle not containing
anything at all.
Add a unit test checking that we actually can't create an SVG from a
.bmp file (which is something that "worked" before).
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.
Unlike under Mac (see previous commit), this never worked correctly in
wxMSW at all, only SetScaleFactor() could be used to change the scale
factor of the bitmaps there.
Fix this and make CreateWithLogicalSize(..., scale) result in
GetScaleFactor() returning the same scale for the resulting bitmap, as
expected, under MSW too.
Also add a unit test verifying that this holds.
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.
This improves the changes of f78db92462 (Avoid bitmap scaling in
wxArtProvider::GetBitmapBundle(), 2021-12-17) and still uses a custom
bundle to avoid scaling the bitmap if possible, but does it in
GetBitmapBundle() itself rather than CreateBitmapBundle().
This allows to also use CreateBitmapBundle() from GetBitmap(), as there
is no possibility of infinite recursion due to calling each of these
functions from the other one any more, and so allows defining art
providers overriding only CreateBitmapBundle() instead of having to
always override both it and CreateBitmap().
Also add a unit test, even if just a trivial one, for these functions,
to at least check that they don't crash.
We often need the logical bitmap size when using it in size computations
involving window size, so add a function returning it directly to
wxBitmapBundle, similarly to wxBitmap::GetLogicalSize(), to avoid using
FromPhys() everywhere.
Also rename the existing wxBitmapBundle::GetPreferredSizeFor() to
GetPreferredBitmapSizeFor() to make it more clear that this is similar
to wxBitmap::GetSize() and so returns the size in physical units.
Closes#22056.
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.
Now wxMSW also stores the scale factor, even if it doesn't use it in its
GetScaledXXX(), so it doesn't seem useful to have this symbol for
distinguishing the platforms with and without bitmap scale factor
support, when we can just use wxHAS_DPI_INDEPENDENT_PIXELS instead in
the only place where this was used.
And as this symbol was added quite recently, in 2c1f4c002d (Add
wxBitmap::SetScaleFactor(), 2021-10-23), we can hopefully just remove it
without breaking any existing code, if we do it right now.
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.
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.
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.
Passing non-const data is inconvenient and error-prone, as data can't be
used again after it was modified by Nano SVG, which resulted in the
button using SVG bitmap not working any longer in the toolbar sample
after recreating the toolbar.
So make it easier to do the right thing, while still keeping the
overload taking non-const data for the situations when avoiding an extra
copy is worth it.
Add nanosvg submodule and use it in the generic implementation of this
function.
This is incomplete yet and, notably, doesn't cache the rasterized
images, but already shows that using SVG images works (at least in the
toolbar sample).
Set window position explictly to (0, 0) to avoid unwanted clipping
if defualt position selected by the system would place it (partially)
outside of the parent window.
There is nothing that can be done about the warnings saying that using
transform matrix is not supported for the given DC kind and it's not
going to change any time soon (i.e. implementing support for transform
matrix for wxSVGFileDC is not planned), but in the meanwhile it results
in a lot of useless output in the CI logs when running the tests, making
it difficult to find real problems in the test.
This commit is best viewed ignoring whitespace-only changes.
Now that these Direct2D tests are compiled, disable those of them that
fail under Wine due to missing support for Direct2D functionality we use
in Wine implementation.
Don't even give a warning message because there would be too many of
them in these tests, just skip them silently.
Since f7247086c2 ("Fix storing wxBitmap data in GdkPixbuf", 2019-09-18),
919a4ec702 ("Fix drawing wxBitmap with mask", 2019-09-18) and other
commits (see #18498, #18508) RGBA wxBitmaps with masks are drawn properly
under wxGTK2 so if source wxImage has both alpha channel and a mask
the target wxBitmap also should have both components.
Since f7247086c2 ("Fix storing wxBitmap data in GdkPixbuf", 2019-09-18),
919a4ec702 ("Fix drawing wxBitmap with mask", 2019-09-18) and other
commits (see #18498, #18508) RGBA wxBitmaps with masks are drawn properly
under wxGTK2 so only wxBitmap raw RGBA data should be transferred to
wxImage RGBA data because mask is stored in the target wxImage separately.
Sizing the images stored in the list should stick to the convention
adopted in the native wxImageList implemented in wxMSW.
Images stored in the list should have the sizes as it is declared for
the list even if provided bitmaps have different sizes.
In case of discrepancies their dimensions should be adjusted accordingly
(cropped or extended).
If image using bitmap and mask colour is added to nonmasked wxImageList we
need to convert effective mask to alpha channel values prior to adding the
image to the native list to preserve transparency.
Bitmaps stored in the list as a result of replacing existing ones should
conform to the same constraints as bitmaps directly added to the list.
These constraints are applied in the shared GetImageListBitmap() function
called both on adding and replacing the images.
Handling mask when converting wxBitmap to wxImage was accidentally
broken by 7e9afad53a (Add real support for monochrome bitmaps to wxMSW,
2020-10-19). Fix this now and reuse the new wxMonoPixelData to make the
code simpler and more readable.
This commit is best viewed ignoring whitespace-only changes, as it
unindents a large block of code.
Closes https://github.com/wxWidgets/wxWidgets/pull/2125Closes#18974, #18975.
In order to be able to use monochrome bitmaps as wxMask, improve support
for them in various ways:
1. Implement loading and saving of monochrome BMP files.
2. Add wxMonoPixelData for direct access to monochrome bitmap pixels.
3. Implement conversion from wxImage to monochrome wxBitmap.
Closes https://github.com/wxWidgets/wxWidgets/pull/2032
This restores the previous behaviour inadvertently changed by bfeae1922d
(Minor optimizations in GetMultiLineTextExtent(), 2020-06-10) and makes
it official by documenting it and adding tests checking for it.
It wasn't completely obviously if this was intentional or accidental
before, but at least wxStaticText itself relied on the old behaviour,
and chances are that so did some code outside the library, so make this
part of the API now.
See #18825.
