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.
This seems more logical and is compatible with wxDC in wxMSW and wxGTK2,
as well as other kinds of DC, e.g. wxPostScriptDC.
It also looks like the current behaviour was unintentional as it
happened only because wxGCDCImpl::DoGetTextExtent() always passed all
non-null parameters to wxGraphicsContext::GetTextExtent(), even if it
didn't need the values for all of them, and thus bypassed the special
case for the empty string which was already present in the latter
function.
Fix this, making DoGetTextExtent() more efficient as a side effect (we
now avoid unnecessary calls to pango_layout_iter_get_baseline() in the
most common case), and also add another test for empty string to
wxGraphicsContext itself, for non-GTK case.
Also document this behaviour and add a test checking for it.
This is consistent with wxToString(wxColour) and seems more useful than
either returning black string representation (as wxMSW used to do) or
asserting (as wxGTK did).
Document this behaviour and add a test checking for it.
Closes#18623.
Also define wxColour-specific matchers to allow comparing RGB(A)
channels to the expected values, replacing the old ASSERT_EQUAL_RGB(A)
macros.
No real changes.
