The Ubuntu 16.04 Launchpad build for armhf failed due to a potential
alignment issue:
/<<PKGBUILDDIR>>/src/kde/AchQtDBus.cpp: In member function ‘int AchQtDBus::notifyFunc(LibRpBase::Achievements::ID)’:
/<<PKGBUILDDIR>>/src/kde/AchQtDBus.cpp:149:59: error: cast from ‘uchar* {aka unsigned char*}’ to ‘LibRpTexture::argb32_t*’ increases required alignment of target type [-Werror=cast-align]
argb32_t *bits = reinterpret_cast<argb32_t*>(icon.bits());
^
This shouldn't be an actual problem, since rp_image's image data is
always 16-byte aligned.
NOTE: Not rebuilding the Ubuntu 16.04 packages for ARM because of this.
(Both the armhf and arm64 builds were cancelled.)
glibc earlier than 2.26 did not have proper wcwidth() values for emojis.
Also, add some Japanese katakana tests. Older glibc wcwidth *does* have
proper wcwidth(() values for katakana, so we can at least test that.
Split the emoji tests into its own unit test.
Instead of defining a constant to either 5 or 4, just switch back to a
C array. We don't get any real advantage by using std::array<> here.
This fixes garbage data being read for tests on 32-bit systems that
aren't using 64-bit time_t, resulting in test failures.
Ported from upstream.
extlib\rapidjson\include\rapidjson\internal\biginteger.h(22,9): error C2220: the following warning is treated as an error (compiling source file src\librpbase\TextOut_json.cpp)
extlib\rapidjson\include\rapidjson\internal\biginteger.h(22,9): warning C4163: 'UnsignedMultiply128': not available as an intrinsic function (compiling source file src\librpbase\TextOut_json.cpp)
extlib\rapidjson\include\rapidjson\internal\diyfp.h(27,9): warning C4163: 'UnsignedMultiply128': not available as an intrinsic function (compiling source file src\librpbase\TextOut_json.cpp)
This is also set by extlib/CMakeLists.txt.
CMake Warning (dev) at extlib/zlib-ng/CMakeLists.txt:145 (option):
Policy CMP0077 is not set: option() honors normal variables. Run "cmake
--help-policy CMP0077" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
For compatibility with older versions of CMake, option is clearing the
normal variable 'INSTALL_UTILS'.
This warning is for project developers. Use -Wno-dev to suppress it.
We're setting these using SET() in extlib/CMakeLists.txt, so having them
as actual options causes CMake to print a bunch of warnings like this:
CMake Warning (dev) at extlib/zlib-ng/CMakeLists.txt:133 (option):
Policy CMP0077 is not set: option() honors normal variables. Run "cmake
--help-policy CMP0077" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
For compatibility with older versions of CMake, option is clearing the
normal variable 'WITH_SSE2'.
This warning is for project developers. Use -Wno-dev to suppress it.
[extlib] CMakeLists.txt: SET(WITH_VPCLMULQDQ ON)
Needed by the Qt4 build:
In file included from src/kde/OptionsMenuButton.hpp:24:0,
from rp.build/src/kde/kde4/moc_OptionsMenuButton.cpp:9,
from rp.build/src/kde/kde4/rom-properties-kde4_automoc.cpp:8:
src/kde/RpQt.hpp: In function ‘QFont getSystemMonospaceFont()’:
src/kde/RpQt.hpp:259:21: error: incomplete type ‘QApplication’ used in nested name specifier
QFont fntMonospace(QApplication::font());
^
This abstracts the differences betwene the Qt 5.2+ version, which uses
QFontDatabase::systemFont(), and the older Qt version, which just uses
the "Monospace" font.
Updated everything to use getSystemMonospaceFont().
Add back the old version for older Qt.
Note that there's a few changes. In particular, RomDataView now uses
the same method as KeyStoreModel; that is, instead of creating a brand
new font using family "Monospace", it gets the application font and
applies the "Monospace" font family. I'm not sure if this will help
at all or not.
Also, we're not disabling QEvent::StyleChange, even though it's unlikely
to be useful without QFontDatabase::systemFont().
gcc-5.4.0 on Xubuntu 16.04 complains, even though it's not possible for
`p` to be used in an uninitialized state:
src/libromdata/Media/Wim_xml.cpp: In member function ‘int LibRomData::WimPrivate::addFields_XML()’:
src/libromdata/Media/Wim_xml.cpp:265:33: error: ‘p’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
char *const dupdesc = strdup(p + 9);
^
RpQt: Inlined installEventFilterInTopLevelWidget() in the .hpp file.
Otherwise, we'd have to link RpQt.cpp in with the XAttrView plugin,
and we can't do that easily because RpQt.cpp has more dependencies.
Add an event filter for the top-level window. This lets us handle
QEvent::StyleChange.
Add all monospace widgets to a vector, vecMonoWidgets. On a font change,
all widgets in this vector will be updated.
NOTE: I'm using std::vector<> instead of QVector<> because QVector has
overhead from using pimpl.
NOTE: There's also QEvent::ThemeChange. Both seem to get emitted here
when the monospace font is changed, so I'm not sure which one is
more "correct".
TODO: Handle font changes in other things that use monospace fonts.
KeyManagerTab: Handle QEvent::StyleChange instead of QEvent::FontChange.
QEvent::FontChange is for if something calls setFont(), not if the
system font changes.
"Monospace" uses Qt's own default monospace font, which is usually
DejaVu Sans Mono. By using QFontDatabase, we can get the monospace
font set by the user in KDE's System Settings.
Updated everything that uses monospace fonts.
NOTE: The XAttr .ui files still have "Monospace". The actual font is
loaded in the main class constructor.
- Use uint32_t for unstaged_idx.
- Print the sub-image index as if it's an Excel column name:
- 1a-1z for the first 26 sub-images
- 1aa-1az for the next 26 sub-images
- 1ba-1bz for the next 26 sub-images
- etc...
See #445: [libromdata - WIM] Unstaged Windows OS installation images not properly supported
Requested by @pivotman319-owo.
TODO: "FLAGS" node contains "Windows Foundation".
Use the number of <IMAGE> elements instead.
This means that a malformed image could have the wrong "number of images",
which is displayed *before* the XML is parsed.
Also use the IMAGE's INDEX attribute for the actual index value.
Use WimIndex.index and WimIndex.unstaged_idx when adding the ListData
instead of manually adding values. This prevents issues where a Wim
image with two unstaged images shows up as a single unstaged image.
Tested with a Windows 7 64-bit Checked disc image.
See #445: [libromdata - WIM] Unstaged Windows OS installation images not properly supported
Requested by @pivotman319-owo.
The dummy value may be off by a few characters depending on timezone and
locale settings.
In my case (GMT-5, en_US), the dummy value is "12/31/1969 12:00:00 AM",
which results in extra spaces if all timestamps are earlier than October
or before the 10th of the month, or possibly before 10 AM/PM.
This might be a bit slower, since all timestamps have to be formatted
twice. (TODO: Cache the formatted timestamps?)
Unstaged images contain sets of components instead of a fully-installed
Windows system. These aren't as common as staged images.
The list of editions appears to be in the display description, though
I don't have an unstaged image to verify this. If the display description
contains "EDITIONS:", and the regular edition field and languages are
both empty, then it will be assumed to be unstaged. The list of editions
will be split and one image will be shown for each edition, using the
image number and a letter.
Should fix#445: [libromdata - WIM] Unstaged Windows OS installation images not properly supported
Requested by @pivotman319-owo.
NOTE: Needs to be verified!
Both clang and MSVC appear to be rather lax with regards to vector
conversions, e.g. implicitly converting from 32x4 to 8x16.
gcc, by default, complains about it:
note: use '-flax-vector-conversions' to permit conversions between vectors with differing element types or numbers of subparts
error: cannot convert '__Uint32x4_t' to 'uint8x16_t'
Instead of adding '-flax-vector-conversions', add macros to make use of
vtbl with the vinterpret*() functions. Note that the vinterpret*()
functions don't change the resulting assembly at all; they merely specify
the explicit intent for the vector conversion.
Also, there are no vinterpret*() functions for the multi-vector types,
e.g. uint32x4x4_t; only for the single-vector types.
It turns out vtbl *does* zero out the destination value if the control
index is "out of range". We'll use 0xFF for this.
This makes the AND mask unnecessary.
ImageDecoderTest still passes with this change.
fromLinear32_neon():
- Remove the PixelFormat::G16R16 case from the has_alpha branch,
since this format doesn't have alpha.
- has_alpha has a simpler meaning. Using "MASK_NONE" for images
with alpha, and "MASK_ALPHA" for images without alpha, is
confusing. The mask was supposed to mean "mask this channel *out*".
fromLinear32_ssse3(): Likewise.
Note that NEON's vtbl instructions doesn't support the bit 7 "zero it"
feature that x86's pshufb supports, so we have to use an AND mask in
addition to an OR mask.
Tested using luminance_alpha_reference_u.ktx2, which has a swizzle
value 'rrrg'. (Also used this for testing the previous commit, which
switched some mask stuff from 8-bit operations to 32-bit.)
This lets us use 32-bit operations instead of 8-bit operations, which
reduces code size and improves performance a bit.
This was already done for por_mask_vals, so I'm not sure why I didn't
do this for pshufb_mask_vals...
Code size difference: (64-bit Gentoo Linux, gcc-14.2.1_p20250301, release build, no LTO)
text data bss dec hex filename
2691 0 0 2691 a83 rp_image_ops_ssse3.cpp.o [before]
2221 0 0 2221 8ad rp_image_ops_ssse3.cpp.o [after]
-470 0 0 -470 -1d6 Difference
[librpbyteswap,librptexture] If arm_neon.h isn't available, don't compile
any NEON-optimized functions.
Just in case someone wants to build rom-properties for an ancient ARM
system that was introduced before NEON...
