Compared to Corrade, the improvement in compile time is about a minute
cumulative across all cores, or about 8 seconds on an 8-core system (~2
minutes before, ~1:52 after). Not bad at all. And this is with a
deprecated build, the non-deprecated build is 1:48 -> 1:41.
This is going to get called from fillGlyphCache() that takes a string,
and thus should be better than one virtual call per character. The
single-character variant still stays, as it's a nice convenience API.
Eventually glyphSize() will get a similar treatment as well.
Took me quite a while to realize what was going on, but in retrospect
it's obvious -- the rasterizer just *rounds* the sub-pixel-positioned
glyph quads to nearest pixels. Which then can cause the neighboring
glyph data to leak to it (because the texture is then sampled not
directly on the edge pixel, but slightly outside of it), or it can also
cut away the edge, when it gets rounded in the other direction.
This was a problem with the original -- laughably inefficient -- atlas
packer as well, but because that packer had excessive padding around
everything, only the second edge-cutting artifact manifested, and that
one is rather subtle unless you know what to look for.
This means the packing is now slightly worse than before and sizes that
previously worked may no longer fit anymore. But since the new atlas
packer is relatively new (well, from September, time sure flies
different here), and the improvement compared to the original packer is
still quite massive, I don't think this is a problem.
Replaces the previous, grossly inefficient AbstractLayouter which was
performing one virtual call per glyph (!). It's now also reusable,
meaning it doesn't need to be allocated anew for every new shaped text,
and it no longer requires each and every font plugin to implement the
same redundant glyph data fetching from the glyph cache, scaling etc. --
all that is meant to be done by the users of AbstractShaper, i.e.
Renderer. The independency on a glyph cache theorerically also means it
can be used for a completely different, non-texture-based way to render
text (such as direct path drawing directly on the GPU), although I won't
be exploring that path now.
It also exposes an interface for specifying script, language,
direction and typographic features. Such interface will be currently
only implemented in HarfBuzz, but that's the intent -- to provide a
flexible enough interface to support all possible use cases that a font
or a font plugin may support, instead of exposing a least common
denominator and then having no easy way to shape a text in a non-Latin
script or use a fancy OpenType feature the chosen font has.
The old public interface is preserved for backwards compatibility,
marked as deprecated, however the virtual APIs are not, as supporting
that would be too nasty. I don't think any user code ever implemented a
font plugin so this should be okay.
To ensure smooth transition with no regressions, the Renderer class and
MagnumFont tests still use the old API in this commit, and their test
pass the same way as they did before (except for two removed MagnumFont
test cases which tested errors that are now an assertion in the
deprecated layout() API and thus cannot be tested from the plugin
anymore). Porting them away from the deprecated API will be done in
separate commits.
The internals are still rather ew, that's for another time, but the goal
here was to make it compile and correctly handle the new variability in
created and passed glyph cache instances. In particular:
- The MagnumFont createGlyphCache() now uploads the texture image
directly, skipping a copy through the CPU-side image which may not
have a size matching the input image. That's kind of nasty (and too
tied to OpenGL), but will be cleaned up once the GlyphCache APIs are
fixed to allow this in a nicer way.
- The MagnumFontConverter will now correctly select a font if the cache
contains more than one, properly deal with glyph caches that either
do or not do image processing, and will fail for array glyph caches
as that's not supported by the current format. It also now has an
early special-case handling for glyph caches with processed images,
where the actual image may have different size (and possibly format),
to match what MagnumFont expects.
Need some regression tests for the upcoming glyph cache rework as
otherwise it'll be too miserable. It now fills the glyph cache image
with some non-trivial data and compares to them, and checks the filled
glyphs for the created glyph cache too.
This also fixes a regression introduced when porting away from STL in
47a1295ab8, where UTF-8 layouting was
reporting extra glyphs at the end. Now UTF-8 support is properly tested
both in the MagnumFontConverter plugin and MagnumFont.
It won't contain just font metrics anymore. Also don't require the
struct to be zero-initialized if opening fails -- simply allow the
plugins to return garbage in that case and save the values only if
opening actually succeeded.
Strictly speaking this isn't an ABI change as the return value isn't
part of the function signature and the struct is still the same, so the
plugin interface version isn't bumped for this change.
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).
Like in Trade, the unatomic exists() + read() pair (and silent failures
if the file exists but can't be read) was replaced with just
Path::read() that now returns an Optional. Besides that, not much worth
mentioning.
Moreover, doing them here would mean the options might get ignored with
no clear reason why. Aaand yes of course this caused MagnumFontConverter
to be skipped for no clear reason on embedded platforms, and uncovered a
setup bug in the test.
Allows the Font and FontConverter plugins be built without TARGET_GL
enabled. That was the last piece missing for making the magnum-plugins
repo completely GL-free.
The current testing workflow had quite a few major flaws and it was no
longer possible after the move of Any* plugins to core. Among the flaws
is:
* Every plugin was basically built twice, once as the real plugin and
once as a static testing library. Most of the build shared common
object files, but nevertheless it inflated build times and made the
buildsystem extremely complex.
* Because the actual plugin binary was never actually loaded during the
test, it couldn't spot problems like:
- undefined references
- errors in metadata files
- mismatched plugin interface/version, missing entry points
- broken static plugin import files
* Tests that made use of independent plugins (such as TgaImageConverter
test using TgaImporter to verify the output) had a hardcoded
dependency on such plugins, making a minimal setup very hard.
* Dynamic loading of plugins from the Any* proxies was always directed
to the install location on the filesystem with no possibility to
load these directly from the build tree. That caused random ABI
mismatch crashes, or, on the other hand, if no plugins were
installed, particular portions of the codebase weren't tested at all.
Now the workflow is the following:
* Every plugin is built exactly once, either as dynamic or as static.
* The test always loads it via the plugin manager. If it's dynamic,
it's loaded straight from the build directory; if it's static, it
gets linked to the test executable directly.
* Plugins used indirectly are always served from the build directory
(if enabled) to ensure reproducibility and independence on what's
installed on the filesystem. Missing presence of these plugins causes
particular tests to be simply skipped.
* Plugins that have extensive tests for internal functionality that's
not exposed through the plugin interface are still built in two
parts, but the internal tests are simply consuming the OBJECT files
directly instead of linking to a static library.
And removing the bundled std::optional implementation. This finally
makes this library compatible with C++17. Since this would be a huge
backwards-incompatible change that would make everyone angry, the
following had to be done in case both CORRADE_BUILD_DEPRECATED and
MAGNUM_BUILD_DEPRECATED is defined:
* Under C++11 and C++14, Containers::Optional / Containers::NullOpt is
aliased to std::optional / std::nullopt. This is no worse than the
state before, when we also provided these symbols.
* Under C++17, where standard <optional> header is available,
Containers::Optional provides implicit conversion to it. Only one-way
conversion is supported, as there was fortunately no Magnum API that
took std::optional via parameter, and there might be some corner
cases that this doesn't cover. The goal is to have all examples
compiling with the old API, at least.
* There's a new test especially for this, which checks that both the
C++11 and C++17 ways of doing things work as they should.
The typedef and conversion is marked as deprecated, so it will spit out
many warnings to push users to upgrade. I hope I can completely remove
this mess soon :/
There will be numerous additions to this one so it made sense to make it
a static library instead of a header-only library. That also allows
CMake users to just link to Magnum::OpenGLTester instead of going
through the pain of a huge branching in order to find a correct
windowless application just to run their tests. It could have been done
even without the static library using a INTERFACE target, but that
wouldn't work on CMake < 3.0 (which, unfortunately, quite a few people
are still stuck with).
Unfortunately it's already heavily used elsewhere so I had to go through
the pain of deprecating the old implementation. The old implementation
was header-only so it can't be just typedef'd to the new one as there
would be linker failures. So the old header is just kept as it was, with
only the macros reduced.
Yeah, sorry, I know, the enums are renamed for second or third time in a
row, first they were Image::Format, then ImageFormat, then ColorFormat
and now PixelFormat. But this time it's final and last time they are
renamed and now everything is finally consistent:
* ColorFormat::DepthComponent -- depth is not a color, thus
PixelFormat::DepthComponent makes a lot more sense.
* There will be PixelStorage classes, which will be stored in images
alonside PixelFormat/PixelType enums, making everything nicely
aligned.
* The GL documentation about glTexImage2D() etc. denotes the <format>
and <type> parameters as format and type of *pixel* data, so now we
are _finally_ consistent with the official naming.
I wonder why did I not choose PixelFormat originally. Anyway, the old
<Magnum/ColorFormat.h> header, ColorFormat, ColorType and
CompressedColorFormat types are now aliases to the new ones, are marked
as deprecated and will be removed in some future release (as always, I'm
waiting at least six months before removing the deprecated
functionality).
I wanted to preserve the parameter-less constructor of tests, but WINAPI
requires fairly ugly entagled set of functions, passing HWND around,
which required storing it in a global var and hoping it is properly
initialized when querying it for it to be passed to application
constructor.
When this was done, it was now fairly easy to support passing also
argv/argc to application constructor, which in the future will enable
selective disabling of extensions for even better test coverage.
This however needed slightly different main() function and thus we now
have MAGNUM_GL_TEST_MAIN() instead of CORRADE_TEST_MAIN(). Using the
latter will result in an assert inside std::optional.
Vladimír Vondruš