GRAPHICS: Flash Font
This PR adds support for SWF flash fonts used by both dragonage games. Since the rendering needs to know what are the neighbour characters of a character, because of kerning adjustment, I decided to move the functionality into a class independent from the rest of the font system. This PR also adds cairo as an additional dependency which is used by the FlashFont class and will be used more extensively in future scaleform PRs. Maybe someone with more knowledge about automake could add the cairo dependency for the automake build.
The issues should now be fixed, and the requested additional things except for the automake stuff are added.
Thanks! :)
I can write the automake/autoconf macro for that, no problem, when we're getting around to merging it.
I took the freedom of adding a small FAQ entry explaining my reasons for using cairo
Now that the release is finally done (yeah, sorry for taking so long), I think I can "unfreeze" this.
Just to make sure, @Nostritius, this is still something you want to see merged, right? If so, I'll re-review this in the coming days and write the autotools macro to check for Cairo.
The conflicts are just in the distribution files, that should be a quick fix, nothing breaking.
To be honest, after a quick search for the current state on software based libraries for shape rendering, I found Blend2D which is relatively new and comes without all that stuff cairo has and we don't need. According to their own benchmark they are even way faster then cairo (which is in our case highly important, since I realized, that generating all shapes required for example for the main menu of dragonage takes a lot of time, about 20 seconds). It was published after I made the decision to stick with cairo. What do you think about it dependency integration wise and compared to cairo? I want to give it a try at least, to see if it fullfills our needs better than cairo.
If it's something small we can drop into xoreos, I'd vastly prefer that over adding a dependency on something huge like Cairo, yes.
Looking at Blend2D, though... powered by asmjit? Oof, not sure that's a good idea. CPU architecture support: x86/amd64, ARM currently only partially. That doesn't really sound like that's really future-proof for porting xoreos.
To further my thoughts on this:
What I would absolutely prefer is if we could pull in a something small, potentially single-file. Not sure something like that exists, specifically for all the features we need.
I'm not all too happy with adding a dependency on Cairo, since it's a huge beast (and it increases by cross-compilation burden). But if we need it to get everything we're using, okay, then that's what we need to do. Cairo is at least an established project, so we can be sure it's reasonable stable and works.
I'm going to veto anything that decreases portability (by depending on specific architectures, for example), sorry. And do we even need heavy-duty JIT stuff? Or are we throwing mountains at ants here?
Does this make sense?
After thinking closely about this and taking a look into blend2d, I would say, it would be better to stick for the moment with cairo, and keep an eye on potential alternatives.
Okay, thanks for researching this. :)
What's the status on this PR now, then? Is it in a state you want to see merged?
(Moved the wrong card, narf, so now there's two spam change entries below :P)
Yes, I would cocnsider this ccode as effectively finished
(WIP branch with this PR merged onto the current master + autotools support: https://github.com/xoreos/xoreos/tree/cairo . I haven't looked at the code yet beyond making it compilable.)