Reply to thread

Message

<blockquote data-quote="morpheus_xx" data-source="post: 1105796" data-attributes="member: 48495">Yesterday I've read a lot more about the text handling. I did wonder why we have to deal with different orders at all inside MP2 rendering. The answer is, that the rext rendering engine is based on FreeType to get the glyphs (single character) from a given font. That glyph is then added to a texture. When a text is going to be rendered, all contained glyphs will be added to the texture when they are needed.The actual rendering then in principle renders every character separately using texture coordinates of the glyph and the &quot;big character map&quot; texture.This is the cause why read order is not yet considered correctly and the partial string reversal could be a temporary workaround. The workaround wouldn't work for Arabic, because there letters are different if they are combined differently. This means &quot;A B&quot; looks different then &quot;AB&quot; or the 'a' inside &quot;ab&quot; might look different to the 'a' inside &quot;ac&quot;. (Correct me if I'm wrong).Now what should we do now?One possible solution would be DirectWrite (available through SharpDX), which allows drawing any text correctly, LTR, RTL and mixed cases are fine. We could replace the current implementation of FontAssetCore by a DirectWrite text renderer, which then either renders directly to render target, or we need to take the way over a Texture that then will be rendered into scene.[USER=140174]@Stéphane Lenclud[/USER] , you wrote in another thread that you have experience with graphic coding, what do you think how we should handle text rendering in future inside MP2? Could the explained rendering of characters be a cause for a performance bottleneck? Would be my proposal a bottleneck?Finally this means a big rework of one central part of rendering engine that requires much work for developing, testing, and fixing. But I think we would benefit of this step.</blockquote>

[QUOTE="morpheus_xx, post: 1105796, member: 48495"] Yesterday I've read a lot more about the text handling. I did wonder why we have to deal with different orders at all inside MP2 rendering. The answer is, that the rext rendering engine is based on FreeType to get the glyphs (single character) from a given font. That glyph is then added to a texture. When a text is going to be rendered, all contained glyphs will be added to the texture when they are needed. The actual rendering then in principle renders every character separately using texture coordinates of the glyph and the "big character map" texture. This is the cause why read order is not yet considered correctly and the partial string reversal could be a temporary workaround. The workaround wouldn't work for Arabic, because there letters are different if they are combined differently. This means "A B" looks different then "AB" or the 'a' inside "ab" might look different to the 'a' inside "ac". (Correct me if I'm wrong). Now what should we do now? One possible solution would be DirectWrite (available through SharpDX), which allows drawing any text correctly, LTR, RTL and mixed cases are fine. We could replace the current implementation of FontAssetCore by a DirectWrite text renderer, which then either renders directly to render target, or we need to take the way over a Texture that then will be rendered into scene. [USER=140174]@Stéphane Lenclud[/USER] , you wrote in another thread that you have experience with graphic coding, what do you think how we should handle text rendering in future inside MP2? Could the explained rendering of characters be a cause for a performance bottleneck? Would be my proposal a bottleneck? Finally this means a big rework of one central part of rendering engine that requires much work for developing, testing, and fixing. But I think we would benefit of this step. [/QUOTE]

Verification