Just the dumbest possible idea I had, and it compares surprisingly well
in both efficiency (~comparable to stb_rect_pack) and speed
(significantly faster than stb_rect_pack with tons of tiny images,
slower with larger ones -- would probably need to SIMD Math::max() and
such, haha). It's the very first implementation without any additional
improvements I have in mind, so it'll likely improve further.
Includes a benchmark with a bunch of "datasets" extracted from both
fonts and large glTF models. The stb_rect_pack file isn't commited as
it's not useful apart from this single benchmark, put it to
AtlasTestFiles/ and recompile.
All std::string arguments are now a StringView, what returned a
std::pair is now a Pair. STL compatibility headers are included on
deprecated builds to ease porting, as usual.
The only *really* breaking changes are in the internals, where an
ArrayView<const char32_t> is used instead of std::u32string, which is in
line with the change done in Utility::Unicode::utf32(); and a Triple is
returned instead of a std::tuple. Behaviorally nothing changed except
that fillGlyphCache() now asserts if the input string contains invalid
UTF-8 (which is also in line with the cahnge done in Utility::Unicode).
This one was spectacular -- ALL uses of it had also #include <tuple> in
order to std::tie() the result into separate major & minor variables. So
much compile time overhead for so little.
There's Containers::Triple now for this instead. Printing a message to
Error in case of a failure might have made sense back in 2010, but now
it absolutely doesn't, so it's additionally wrapped in an Optional now.
Also looks like the actual use without "convenient" std::tie() is a lot
less verbose. Haha.
Using Containers::Pair allows me to make certain Range APIs constexpr
that weren't possible in C++11 before. Compared to std::pair it's also
trivially copyable, which is a nice property when storing it in various
growable containers.
As usual, the <Corrade/Containers/PairStl.h> include is in place to help
people with porting, although in many cases this change will be
breaking. I had to do it at some point anyway, so the earlier it is the
better.
This makes them consistent with window and framebuffer size queries,
that are also not cached but queried every time. It fixes a case where a
global UI scaling change in the OS triggered a viewport event but the
event didn't actually have the DPI scaling value updated.
It doesn't however handle actual explicit DPI change events yet, that's
another nightmare altogether.
Partially needed to avoid build breakages because Corrade itself
switched as well, partially because a cleanup is always good. Done
except for (STL-heavy) code that's deprecated or SceneGraph-related APIs
that are still quite full of STL as well.
Same as the corresponding change in Corrade, this allows each function
to explicitly specify its dependencies, making it no longer depending on
what a particular Emscripten version decides to include by default, or
forcing users to painstakingly fill the EXPORTED_FUNCTIONS array when
linking the final executable.
It also allows the code to eventually get conditionally included or not
with preprocessor branches, for example to not include environment
queries for code that won't ever access Node.js console.
It's now possible to choose between low power, high performance and
default, while before it was only possible to switch between low power
and high performance. The old flag is an deprecated alias to the
low-power one.
This reverts commit 6bb0179c65 from 2018,
which in turn reverted commit f6ba4111e1,
which in turn reverted commit 4ce2875262
from 2015. The related Emscripten PR was merged in 2018, so it's safe to
assume everything works as expected nowadays.
Which also means I can finally delete my Emscripten fork that contained
the original branch that attempted to add glDrawRangeElements() in May
2015, before WebGL 2 was even supported in Emscripten, or Firefox.
This makes the minimal supported Emscripten version 1.39.5. With some
more effort this could be changed to 1.38.27, but I don't think anybody
needs that.
AsciiToString is not included by default on 3.1.21+ and including it is
basically impossible on the library side because I don't think they
fixed the case of supplying multiple DEFAULT_LIBRARY_FUNCS_TO_INCLUDE
options on the command line in order to concatenate those lists yet.
Also, given that UTF8ToString is probably already used in other places
since it's included by default, using AsciiToString would only mean
inflating the JS code.
So far this was only possible by creating a temporary MeshView, while
everything else (index/vertex count, base vertex, base instance, ...)
was changeable directly on the Mesh.
The web isn't broken enough yet, apparently. Support for both of those
extensions was added in early 2020 (and I think I remember even seeing
them listed as supported in some browsers), one of them was renamed
mere two months later, one in January 2023.
And I discovered just by accident, the browsers *of course* don't even
bother advertising both to have some transition period. Or maybe that
transition period happened, for 3 weeks in January, and if some
developer didn't notice in that time, "it's their fault". Or maybe it's
my fault, for attempting to use an extension that was stuck in a "draft
status" for four years. THE WHOLE WEB IS EITHER IN A "DRAFT STATUS" OR
"DEPRECATED", THERE'S NOTHING IN BETWEEN, FFS!
Constant needless churn, UGH.
As this is now documented, it means 3rd party code can now directly make
use of these without having to reinvent the same logic, or worse,
rediscover the same driver bugs.
The compatibility.glsl file however stays private -- I don't expect
real-world projects needing *that much* diversity in their supported
GLSL versions, often the baseline is GLES 3.0 which makes a large part
of the file unnecessary, and the projects might choose to for example
always have implicitly queried uniform locations to not have to
maintain two code paths.
It should be returning twice the value, this is the half-angle. Sad that
this went unnoticed for so long, extra bad points for me to have a
complicated test but not actually verifying that the returned value
makes sense, sigh.
A *nasty* option would be to just fix it, but -- even though there's a
chance nonbody ever used it since nobody ever complained -- it would
introduce breakages to any code that fixed it and that's something to
definitely not do in a trusted codebase. So it's instead deprecated,
firing an annoying warning to whoever might have called it, and there's
a (temporary) replacement called halfAngle() that does exactly the same
but is named appropriately.
Then, once the deprecated angle() is removed (the usual deprecation
period, so a year or the span of two releases, whichever takes longer)
and enough time passes (so another year at least), I'll reintroduce it
with a correct return value.
Same as the corresponding Corrade change. Should make
MAGNUM_BUILD_STATIC_UNIQUE_GLOBALS working also in cases where Magnum is
linked to just DLLs but not the main application executable. Such as
various plugins or native Python modules.
It isn't a nice UX to force users to hardcode a DLL name of their own
application when building a *dependency library*, but is a simple enough
middle ground between global symbol deduplication not working at all and
having to loop through all possible DLLs with EnumProcessModules() until
a symbol is found.
Vladimír Vondruš