[Rejected] Kanji/Hiragana/Katakana support for My Anime 2 plugin (core and fontengine patch) (1 Viewer)

[mpiva]

I'm adding support for Kanji charsets in My Anime 2 plugin.

Currently mediaportal is unable to create only selected characters from the UTF-16 Range (0-65535).
If all the UTF-16 range is selected, Textures will become too big, and probably unusable (Scaling)

I created an util that creates the texture fonts only with the necessary characters (Mixing the Skin font, with the Meiryo [Japanese] family font), and is compatible with current mediaportal with two changes:

1) Increasing de Texture Coords in Fontengine from 8000 to 65536 and recompiling the dll. (fontEngine.dll)
2) Changing the fonts.xml in the skin, so the selected fonts <endchar> matches the endchar in the generated texture fonts.



This above approach works but have side effects.


1) New fontengine.dll, that belongs to media portal (So changes must be submitted)
2) If cached fonts are deleted and mediaportal tries to regenerate them, since the <endchar> in fonts.xml is too big it will takes ages and probably generates unusable fonts.

Here are the two changes so there will be no side effects...

CHANGES

fontEngine

fontEngine.cpp

From:

#define MAX_TEXTURE_COORDS 8000


To:

#define MAX_TEXTURE_COORDS 65536


MediaPortal Core

GUIFont.cs

//TextureCoords are initialized with (EndCharacter-StartCharacter+10)


From:

_textureCoords = (float[,])b.Deserialize(s);
s.Close();

To:

_textureCoords = (float[,])b.Deserialize(s);
_EndCharacter=_textureCoords.Count()+_StartCharacter-10;
//This will ensure EndChar is get from the bxml instead the xml, since regeneration of 65536 chars is imposible by current MediaPortal implementation, and can be problematic.
s.Close();


With these two changes, fonts.xml remains without changes in the skin, and fontEngine character limit is removed.

I don't see any side effect only a slight increase the memory consumption with fontengine allocating (4*(65536-8000)) bytes more memory.

 

[misterd]

I reject this patch at it is too risky too include it at this stage of MP 1.1.0. Mostly there will be side-effects on system with lower hardware specs, because of the increased memory usage. :sorry:

MisterD

 

[mpiva]

What about using a malloc, instead of fixed number of possible coords? Since most of the font included in the skin uses only the first 256 or 1536 characters from the UTF-16 area, there is a overhead of (8000-1536) * 16 bytes of wasted memory per font, knowing there is 20 static fonts, that will be 2 Meg less memory used by the fontengine.dll on normal behavior. If we use a malloc (new) it'll get exactly the number of coords/ necessary for the font we will free that memory also.

There is no other easy way of doing it, without rewrite fontengine.dll and media portal engine to use an index instead of direct mapping the whole utf-16 area.

Actually mediaportal is very limited on the support of other charsets besides roman.

I'll include a patch that alloc the memory instead of having it fixed from the heap.