This reverts 3b3169fa15 (Fix refresh problems when scrolling with
mousewheel in wxUniv/MSW, 2021-09-23) (see #2525) and replaces it with a
wxUniv-specific workaround in wxScrollHelperBase::HandleOnScroll().
Closes#2640.
These functions return the colour components as unsigned int and so
promote to this type in arithmetic expressions, unlike unsigned char
returned by the existing accessors without the "Get" prefix, which
promotes to (signed) int and results in gcc 12 -Warith-conversion
warnings when the result is then converted to unsigned, as it happened
in our own wxColour::GetRGB() and GetRGBA() functions and would probably
happen in a lot of code outside wx, which could also be updated to use
the new functions instead of inserting casts.
Allow creating wxBitmapBitmap from SVG image stored in an application
resource on the platforms where wxHAS_IMAGE_RESOURCES is defined.
On Windows, load the bundle from a resource with RT_RCDATA type and on
MacOS from a file with an extension "svg" placed in the "Resources"
subdirectory of the application bundle.
Closes#22061.
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.
When SetPage() was called during the webview was still initializing
it would silently fail. This will now load the contents when the
webview is ready. Additionally error handling for the underlying
NavigateToString() has been added so it wont fail silently.
Closes#22052.
Performance tweak for samples/display, resulting in a much faster
application start, particularly when built in debug mode, when Windows
messages are dumped to the system debug channel for
inspection/diagnosis.
Speed up the Append() loop below by foregoing the repeated resizing of
the choice drop-down via repeated calls to GetBestSize() which happens
deep inside the Append() call chain and executes another inner loop
calling SendMessage() to get the control contents. (This exhibits
1/2*O(N^2) behaviour thanks to the linear growth of the length of the
inner loop to the length of the outer loop (= number of items to add),
while it is re-executed for every new added item.)
With the 'display' sample, that's about 500+ rounds and about 500*500/2
SendMessage() calls less now on my dev/test rig, taking noticeable time
to start the display application.
---
Issue was found due to the barrage of '(winmsg)' Windows Message debug
log lines zipping by in the monitor app when the sample was build in
Debug Mode. Only significant difference with the Release Build is those
debug lines being output, hence the performance gain is less, but still
measurable, in a Release build. When the machine is otherwise severely
loaded (UI render core maxing out), "measurable" becomes "obnoxiously
noticeable" again on Win10/64.
Closes#22049.
Add an event which can be handled by the application to determine the
splitter position when the splitter window itself is resized.
This can be used to e.g. preserve the splitter at the given proportion
of the window (and not just in the middle, as it would be already
possible by using gravity 0.5).
Closes#22035.
Extend the existing use of wxIcon in wxDataViewIconText,
wxDataViewCheckIconText, the corresponding renderers and
wxDataViewTreeCtrl to wxBitmapBundle.
As with the other classes, the existing setters have been preserved as
they remain almost entirely compatible with the existing code and the
return type of the existing getters was preserved, with new getters
being introduced for returning wxBitmapBundle only where they're really
required.
Update the sample to use wxBitmapBundle with its wxDataViewTreeCtrl.
Use FromDIP() to ensure that it is not too small when using DPI scaling.
Also make the code slightly more clear by using a meaningful variable
name instead of a (duplicated) comment.
Some of them had been already updated to return the values scaled
appropriately for the current DPI in 56fab0aabb (Improve wxDataView on
DPI change, 2019-01-10), but not all, so add the missing calls to
wxDataView{Progress,IconText}Renderer too.
The change of dcdcbbe078 (Fix wxDataViewCheckIconTextRenderer icon size
with GTK3, 2020-09-17) should really apply to all platforms, especially
those with DPI-independent pixels (a.k.a. really logical pixels), such
as Mac, to have the correct icon sizes in high DPI.
These checks don't seem to make any sense at all, even though they were
there ever since this classes was added in a75124d0da (Added
wxDataViewTreeCtrl, 2007-12-01), and, in fact, were clearly harmful
until they were fixed in e6a2aa5ae3 (Show correct icon for branch nodes
in wxDataViewTreeCtrl, 2018-09-12).
But it seems that even this wasn't the right thing to do, as there
doesn't seem to be any reason to not call ItemChanged() even for the
controls not using images, so just remove them completely.
This is just a convenient wrapper for GetBitmap() that will be useful in
the classes using wxIcon in their public API to preserve compatibility
after switching to using wxBitmapBundle instead of wxIcon internally.
Embed SVG data of the wx logo into the library itself to make it
available to all wx programs, including the samples. This is a bit
wasteful, but <12KiB is not really noticeable compared to the library
size.
This is similar to the existing png2c, but works for any binary data,
not just PNG files.
Another small difference is that this script puts 16 bytes per line
instead of 8 -- this still results in reasonably short lines, but twice
shorter files, so seems to be worth it.
If the art ID is unknown, return an invalid bitmap bundle immediately
rather than returning a non-empty, i.e. apparently valid, bundle which
will be unusable later, as its GetBitmap() will always return an invalid
bitmap.
This allows to just skip using the image if wxArtProvider can't create
it, for whatever reason, rather than asserting when trying to use an
invalid bitmap later, which can often be fatal because it can often have
from wxEVT_PAINT handler and so result in reentering assert handler.
This doesn't really matter for wxMSW, as scale factor is not used by
wxIcon::GetLogicalXXX() anyhow, but it is used by GetDIPSize(), so it
seems better to still preserve it here.
This makes them available in wxIcon (and, less importantly, wxCursor)
too which is needed in order to use icons correctly in high DPI.
This is also more consistent with the other platforms, where wxIcon does
have these methods.
Document these methods in wxIcon now that they're available there under
all platforms and also document wxIcon::GetSize() which had been
available even before, but wasn't documented.
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.
It seems better to round, rather than truncate, in ToPhys(), for the
same reasons as in wxBitmap::CreateScaled() (see parent commit), and
then ceil() mustn't be used in FromPhys() neither, as this would break
round-tripping via both functions.
So, finally, keep the behaviour simple and, hopefully, the least
surprising, by just rounding the result in both functions.
Round the result of the multiplication by possibly non-integer scaling
factor rather than truncating it. This is more consistent with wxMSW and
other ports not using DIPs (wxOSX doesn't matter, as the scale factor
can only be an integer there anyhow) and seems to be more useful.
E.g. previously creating a bitmap of logical size 5 at 150% DPI scaling
would create a 7px bitmap, for which GetLogicalWidth() would return 4.66
that would be truncated to 4, and not 5, when assigning it to an int,
while now a 8px bitmap will be created and both rounding or truncating
its GetLogicalWidth() value of 5.33 results in the more expected 5.
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.
These functions have better names than the existing GetScaledXXX() ones,
so add them to be able to use them in the new code, even if we still
keep the old ones for compatibility.
