|
|
|
[
Permlink
| « Hide
]
Khyota Wulluf added a comment - 26/Oct/08 08:15 AM - edited
Agreed, but Pango is already a dependancy of the viewer, what is it being used for now then?
The current LL viewer for Linux depnds on pango. The viewer does not use pango directly, but GTK depends on it. LL viewer uses GTK when it needs to show OS-native dialog boxes. For example, file chooser dialog box when uploading textures. Listed file names or button labels on the file chooser dialog is rendered using pango. If you have a tga file whose file name is in Arabic, for example, it is listed properly on the file chooser dialog (assuming you have an Arabic font installed.)
This is one that would be great to discuss on sldev once Tofu gets back from vacation next week.
I'm uploading my development snapshot as of 2008-10-31 as a form of a patch. It is far from complete, but it works in some measure.
The current patch is tested only on Linux. I also put some sample texts in-world at Hippotropolis/42/22/23. Please try it to get some feeling what pango can do. I succeeded in building the patched viewer (snapshot 20081031) on Windows using VC++ Express 2005. No changes on the patch itself. A building instruction is attached as snapshot-20081031-win32build.txt.
Tested this on my debian standalone builds and apart from 2 minor conflicts in the patch (we both make the same fix for glActiveTextureARB and that incorrect typedef) it worked perfectly and all sample notecards worked out of the box and displayed correctly for me. Nice work!
I was hoping that changing the font rendering engine would maybe fix the font corruption i see on my laptop but this is no different, its 100% the same as without pango. I updated my patch. It is snapshot-20081123.diff in the attachment snapshot-20081123.zip. This patch is still against 1.21.6 source. It works both on Linux and Windows.
I also prepared prebuilt Windows binary for easy testing. It is available on http://cid-88858bc052aea782.skydrive.live.com/self.aspx/SecondLife/snapshot-20081123-win32.zip For Robin: This patch adds "Reload Font" command in Advanced menu (under Advanced > Text.) Can you try it when you experienced the corruption? A pointer to the JIRA issue of your problem (observed in the LL viewer) might also be a help. Argh ! Pango....
Pango is incredibly slooooooooowwwww when compared to FreeType (it's one of the reasons why GTK2 applications are so much slower than GTK1 ones). Did you ever try to add an "export MOZ_DISABLE_PANGO=1" in the start script of Firefox ?... If not, try it and see how the Firefox renderer flies after that. Personal benchmarks in Firefox show that Pango is at least twice slower than FreeType. I would therefore strongly suggest that before any such patch is adopted, a serious benchmarking is done to see how much Pango slows down the viewer. in fact, apart from "exotic" languages, UTF-8 support is not even necessary in the viewer. I personally use it on ISO-8859-15 systems and can get all the accented characters I need in the notecards etc. For people like me (i.e. all American, most African, Australian and the vast majority of European people), Pango and UTF-8 in general are a pure waste of processing power. For now, and till I get proofs that it won't slow down the viewer (especially on "old" computers with single core CPUs) I'm "voting against" (well, by this comment as there is no way to vote against a patch in the JIRA) this patch. EDIT: I would be ready to vote for a patch in this vein but that would allow to disable Pango altogether via an environment variable (like what Firefox allows). I wouldn't discredit Pango on reasons of speed - we have a big glyph cache.
@Tofu
Care of giving benchmarking figures, then ?... I gave mine for Firefox, but won't have time/will to do it in SL. I will only trust it's not slower in SL once I see it demonstrated. Hi Alissa,
In response to the wiki page's concerns - for Linux I'd strongly recommend targetting a runtime Pango 1.12 (or earlier - as early as you can tolerate). This corresponds to the earliest version of Ubuntu (6.06) which we support, although conservatively it would still be very nice to support somewhat older systems than that. Sadly I have no confidence that we can ship our own favourite pango version on Linux and have it not interfere fatally with the expectations of the random system GTK, so we need to rely on a lowest-common-denominator system version. For modern distro-specific builds this is of course not a concern, but for the non-distro-specific generic Linden build we'd still have to assume Pango 1.12 (ideally earlier) or this might not be shippable turned on by default on Linux. OSX and Win32, where it's probably safe to ship any favourite Pango version, should be fine. n.b. featurettes-8 now has the beginnings of some font system overhaul - now the glyph cache should be significantly more effective. Vir Linden is looking into our font system limitations and is considering the Pango proposal - thanks. I updated my pango patch. It is included in the attached file snapshot-20081213.zip. It is against 1.22.3 (105377) source.
Macintosh build instruction is added, some bugs are fixed, and some more debug options are added. Tofu, This patch still requires pango 1.16 or later. I'm not sure targetting at pango 1.12 is reasonable, but I'm researching the possibility for now. Faster is not always better. I find that FreeType is hard to manage to in non-US contexts. It may work for a specific build, but then it only can be said to work to that specification and no more. I find users want more, and when the builds are modified to greater needs, then the specific build is not workable. I believe anybody who has tried to build the viewer beyond the LL official builds understand what I mean here without the need to give case details of any particular experience. FreeType is great for what it achieved, yet Pango has achieved a great breath of usability to more people.
I don't know if I'll use this patch in my build, but I'll I plan to drop FreeType and other font renderers such that Pango will be the only one supported. This may make some wonder how to handle features like floating text, and I'll simply ask why the floating text doesn't work like how avatar imposters now work, as that would solve many issues floating text now has, and any other worry about 'rendering the same glyphs every frame'. @Dzonatas
> Faster is not always better. It is with this kind of twisted reasoning that owners of "old" computers (single core CPUs and pre-8800 Nvidia or equivalent ATI cards) were left out in the blue (with frame rates as low as 3fps when v1.19.0 and previous viewers are able to give well over 30fps on such computers) when LL forced Windlight down our throats... > I find that FreeType is hard to manage to in non-US contexts. Please, elaborate... Such affirmations bring nothing to the debate without a clear demonstration. As a counter example, I will simply cite my own experience with Freetype and Pango in a "non-US context" (ISO-8859-15, i.e. Western Europe charset): Freetype never ever had any trouble rendering texts (including in Firefox), while Pango is so slow (even on modern computers) that it is a real pain in the a.. and brings nothing for European charsets. Pango is not a rasterizer. It needs FreeType to turn glyph outlines into bitmaps.
Not everyone on the world writes right-to-left, one letter next to another, with a space between words, like stacking books on a bookshelf. Some of those people are also Second Life Residents. LL is moving to Qt from GTK+ , which Pango is designed to work with. (Though I wish they don't have to...) @Henri,
> It is with this kind of twisted reasoning that owners of "old" computers (single core CPUs and pre-8800 Nvidia or equivalent ATI cards) were left out in the blue (with frame rates as low as 3fps when v1.19.0 and previous viewers are able to give well over 30fps on such computers) when LL forced Windlight down our throats... That only supports what I have found so far here: http://lists.secondlife.com/pipermail/sldev/2009-June/014557.html > Please, elaborate... Such affirmations bring nothing to the debate without a clear demonstration. As you can also see in the mail above, you are also free to explore the changes I have made to the LL derived code in MonoVida: Do take the avatar imposter (or billboarding, or dynamically-rendered-and-cached textures) into consider as one example that could make an improvement on floating text. Given that, I don't think it is fair to blame Pango for being slow. > Pango is not a rasterizer. It needs FreeType to turn glyph outlines into bitmaps.
The choice to use Pango is more of a stable distribution rather than what base renderer it uses, which the base renderer could be different on each platform. >LL is moving to Qt from GTK+ , which Pango is designed to work with. Qt, the next generation of it, is not set in stone as of yet like some people's decisions to us it. It is being developed on the Mac, said to be also targeted for MS Windows, but no clear support for Linux. I've merged and tested the patch with MonoVida. I think this will work very well to remove dependencies to FreeType. Gtk offers a few renderer options, and lately it tends to default with Cairo based render. I think Cairo would make it much easier to create dynamic textures for text.
Alissa noted the concern about content breakage over the difference in text. The text already renders quite differently on each platform today, however, without the patch. The only way to be sure textual content is the same on each platform is to use uploaded textures. With the hint of temporary textures, the dynamically created text textures could be worked together with those ideas, too. Anyways, here is the issue on MonoVida jira: http://jira.dzonux.net:8080/browse/MVS-43 Good patch Alissa! Uploaded an updated patched based on 1.22.11.
It'll probably needs some extra updates with the font changes from latest snowglobe/1.23.4 build. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Use pango for text rendering
