Tree: 13158fb6cd

apple-crashy-msaa-default-framebuffer

audio-import

catastrophic-cross

chainsaw-surgery

dpi-change-events

euler-xxx

findsdl-include-root

gltestlib-symbol-duplication

gpu-preference

inverted-ranges

ktx1-detection

master

meshdata-cereal-killer

mousecapture

multiwindow

next

sceneconverter

scenedata-optimizations

simd

vectorfields

zerocopy

snapshot-2013-08

snapshot-2013-10

snapshot-2014-01

snapshot-2014-01-compatibility

snapshot-2014-06

snapshot-2014-06-compatibility

snapshot-2015-05

snapshot-2015-05-compatibility

v2013.08

v2013.10

v2014.01

v2014.06

v2015.05

v2018.02

v2018.04

v2018.10

v2019.01

v2019.10

v2020.06

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from '13158fb6cd'

${ noResults }

Commit Graph

2 Commits (13158fb6cd4fcb29c838ecc964a8baa41a7c1e86)

Author	SHA1	Message	Date
Vladimír Vondruš	eaaa34b3fb	Text: rethink AbstractShaper::shape() empty input and failure behavior. ... Empty input was asserting originally, but such strict behavior doesn't seem to be useful in practice as all application code would need to explicitly make sure that shape() isn't called if the input or the input range is empty. In particular, I hit this assert as soon as I rebuilt and ran magnum-player, and the assertion didn't really uncover any bug or make anything better by firing. Treating zero glyph output as a failure also isn't good -- rendering for example a string of whitespace may also result in zero glyphs on the output, which isn't a failure. Plus it's currently unclear what should actually be a failure -- neither FreeType nor HarfBuzz really have a concept of the shaping operation failing, hb_shape() returns void -- so special-casing glyphCount() being zero as a failure just doesn't make sense. This thus means the doScript(), doLanguage() and doDirection() implementations are now called always, regardless of whether shape() was called at all, or whether it produced any glyphs. This allows the shaper for example to give back a detected script etc even if the actual input range to shape was empty.	3 years ago
Vladimír Vondruš	ab8dc070c4	Text: new AbstractShaper interface for shaping. ... 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.	3 years ago