Istnieje wiele pytań dotyczących renderowania czcionek OpenGL, wiele z nich spełnia atlasy tekstur (szybkie, ale błędne) lub tekstury łańcuchowe (tylko tekst stały).

Jednak te podejścia są słabe i wydają się być nieaktualne przez lata (a co z użyciem shaderów do tego lepiej / szybciej?). W przypadku OpenGL 4.1 pojawia się znakomite pytanie dotyczące „tego, czego należy użyćdzisiaj?::

Co to jest najnowocześniejsze w renderowaniu tekstu w OpenGL od wersji 4.1?

Więc,co powinniśmy dzisiaj używać w iOS GL ES 2?

Jestem rozczarowany, że wydaje się, że nie ma żadnego open-source'owego (lub nawet komercyjnego rozwiązania). Wiem, że wiele zespołów wysysa to z siebie i spędza tygodnie dev time na wymyślaniu tego koła, stopniowo ucząc się, jak jądro i przestrzeń itd. (Ugh) - ale musi być lepszy sposób niż ponowne napisanie całości „czcionek” od zera?

O ile widzę, istnieją dwie części:

Jak renderować tekst za pomocą czcionki?Jak wyświetlić dane wyjściowe?

W przypadku 1 (jak renderować) Apple zapewnia WIELE sposobów na uzyskanie „poprawnego” renderowanego wyjścia - ale „łatwe” nie obsługują OpenGL (być może niektóre inne - np. Czy istnieje prosty sposób mapowania wyjścia CoreText do OpenGL?).

Dla 2 (jak wyświetlać) mamy shadery, mamy VBO, mamy tekstury glifów, mamy tekstury wyszukiwania i inne techniki (np. Rzeczy OpenGL 4.1 połączone powyżej?)

Oto dwie popularne metody OpenGL, które znam:

Atlas tekstur (renderuj wszystkie glify raz, następnie renderuj 1 x teksturowany quad na postać ze wspólnej tekstury)To jest złe, chyba że używasz czcionki bitmapowej z lat 80. (a nawet wtedy: atlas tekstury wymaga więcej pracy, niż mogłoby się wydawać, jeśli potrzebujesz poprawnego dla czcionek nietrywialnych)(Czcionki nie są „zbiorem glifów” jest ogromna ilość pozycjonowania, układu, zawijania, odstępów, kerningu, stylizacji, kolorowania, ważenia itp. Atlasy tekstur zawodzą)Naprawiono ciąg (użyj dowolnej klasy Apple do prawidłowego renderowania, następnie zrzuć dane obrazu kopii zapasowej i prześlij jako teksturę)W kategoriach ludzkich jest to szybkie. W renderowaniu klatek jest to bardzo, bardzo powolne. Jeśli robisz to z dużą ilością zmieniającego się tekstu, liczba klatek na sekundę spadaTechnicznie jest to w większości poprawne (nie do końca: w ten sposób tracisz trochę informacji), ale jest bardzo nieefektywne

Widziałem też, ale słyszałem zarówno dobre, jak i złe rzeczy na temat:

Imagination / PowerVR „Print3D” (link uszkodzony) (od facetów, którzy produkują GPU! Ale ich strona przeniosła / usunęła stronę renderowania tekstu)FreeType (wymaga wstępnego przetwarzania, interpretacji, dużej ilości kodu, dodatkowych bibliotek?)... i / lub FTGLhttp://sourceforge.net/projects/ftgl/ (plotki: powolne? buggy? nie aktualizowane od dłuższego czasu?)Font-Stashhttp://digestingduck.blogspot.co.uk/2009/08/font-stash.html (wysoka jakość, ale bardzo wolna?)1

W obrębie własnych systemów operacyjnych Apple / standardowych bibliotek znam kilka źródeł renderowania tekstu. Uwaga:Większość z nich wykorzystywałem szczegółowo w projektach renderowania 2D, moje stwierdzenia na temat generowania różnych renderów są oparte na bezpośrednim doświadczeniu

CoreGraphics z NSStringNajprostszy ze wszystkich: renderuj „w CGRect”Wydaje się, że jest to nieco szybsza wersja podejścia „naprawionego ciągu”, którą polecają ludzie (nawet jeśli spodziewałbyś się, że będzie taka sama)UILabel i UITextArea ze zwykłym tekstemUwaga: NIE są takie same! Nieznaczne różnice w sposobie renderowania tekstu smaeNSAttributedString, renderowane do jednego z powyższychPonownie: renderuje inaczej (różnice, które znam są dość subtelne i klasyfikowane jako „błędy”, różne pytania SO na ten temat)CATextLayerHybryda między czcionkami iOS a starym renderowaniem C. Używa „nie w pełni” zmostkowanego CFFont / UIFont, który ujawnia więcej różnic renderowania / dziwnościCoreText... najlepsze rozwiązanie? Ale bestia sama ...