It doesn't seem to be useful and wasn't really specified in 2 out of 3
existing calls to this function and was probably wrongly specified in
the remaining one, so just remove it for now, it can always be added
later if we decide what exactly should it do.
Only assign known good values of the index to "indexLast" as otherwise
we could end up returning an invalid index value from it if "indexBest"
was never set and the last index wasn't a valid one, as it happened in
wxBitmapBundleImplSet containing an original bitmap and a x2 scaled copy
of it, which shouldn't be used for further scaling.
Add a unit test checking that this bug is fixed now.
Always rounding non-integer scale when upscaling is wrong, as we could
be able to upscale an existing x1.5 image to e.g. 300% DPI scaling with
relatively good results, so only do it if there is no available scale
that exactly divides the requested one.
Add a previously failing unit test which passes now.
It's not necessarily the largest bitmap, but one which may be scaled
using an integer factor.
Fix the tests to expect the correct results, now that they actually
pass.
Check not only that the resulting bitmap has the right size, but also
that it was obtained by scaling the correct bitmap.
Define the required machinery to allow using CATCH CHECK_THAT() macro to
succinctly verify both.
Note that this doesn't change the existing tests, but just rewrites them
in a new form and also adds more tests for a bundle with 3 bitmaps.
Doing anything else results in really poor results, so don't even try
scaling images by 2.25, for example -- scaling by 2 looks much better
and the size difference is relatively insignificant and definitely not
worth the difference in quality.
Don't use external image files, this makes it simpler to run the test
(it can be now done from any directory) and also experiment with it
(e.g. by making the test image fully transparent or fully opaque).
Remove the now unneeded .ico file but keep the .png one still used by
another test.
Don't take the value of "mask" parameter of wxImageList constructor too
prescriptively, it predates support for alpha in wxWidgets by many years
and was never meant to actually suppress using it.
Instead, do the best thing we can in all cases, i.e. use alpha if it's
specified and supported and use mask otherwise. But only create the mask
from light grey colour if we have nothing else if "mask" is true in
wxImageList constructor, as this is a potentially destructive action
that must not be performed if the user has explicitly decided to set
this parameter to false.
Incidentally fix handling of alpha with comctl32.dll v5 (which is used
in the absence of any manifest) by converting it to a mask in this case:
this is not ideal, but better than just using black background as it
happened before, and restores pre-3.1.5 behaviour.
Also simplify the generic version which just has to create the default
mask if necessary and doesn't have to do anything at all in all the
other cases.
Note that these changes required relaxing some of the existing unit
tests as wxMSW implementation now can add alpha channel to the bitmaps
that didn't have it -- but this is a more useful behaviour, and so it
makes more sense to adapt the tests to it rather than doing a less
useful thing just to conform to the tests.
This commit is best viewed with git --color-moved
--color-moved-ws=ignore-all-spac options.
Closes#22349.
Debugging confirms that DPtoLP() simply returns wrong (i.e. different
from that returned under actual MSW) result when using Wine, so just
account for it in the test as it seems to be better than just skipping
the test entirely under Wine and there doesn't seem to be anything else
to do.
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.
This is similar to db6d565fad (Handle wxDC scale factor in wxBitmap ctor
taking wxDC in wxMSW, 2022-04-10), but for the constructor taking
wxImage and wxDC -- it should also use the DC scale factor, even if it
is not used for scaling the bitmap size in this case.
Add a unit test checking for this.
This is similar to 7382e99bbb (Create bitmaps even when given a wxDC
without an HDC in wxMSW, 2022-04-10) and does the same change to
wxBitmap ctor from wxImage and wxDC -- and also extends the unit test to
check for this under wxMSW, which is the only port in which this ctor is
currently available.
When using wxBitmap ctor taking wxDC, the bitmap should inherit the
scale factor of the DC, both because it's already the case in the other
ports and because it makes sense to do it.
Add a unit test checking that this is the case in all ports now.
It seems wrong to just fail to create the bitmap entirely if a not
wxMSWDCImpl-derived wxDC is provided to wxBitmap::Create(size, wxDC)
overload, especially because no check is done to see if the associated
HDC is non-null for wxMSWDCImpl-derived classes.
Instead, simply create a DIB-based bitmap with the specified size, as
this seems more useful and less surprising and was already the behaviour
in the other ports.
Add a test ensuring that this remains the case in the future.
Simplify the code by more or less reverting c7619cf139 (Replace a
template function with template class to fix VC6 build., 2012-11-12)
which shouldn't be necessary any longer as VC6 is not supported since a
long time.
No real changes.
This commit is best viewed ignoring whitespace-only changes.
Fix crash in this function introduced by 9e5c8a8027 (Respect bitmap
content scale factor in wxMSW wxMemoryDC, 2022-03-26).
Also add a unit test ensuring that this doesn't get broken again under
MSW, which seems to be the only place where it works.
Closes#22240.
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.
