100570 - add support for anti-aliased fonts (Render); Part 2

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[kill this account]

this is a continuation of bug 82076 which has passed 4,000 lines of comments
and is thus hard to scroll.

Comment 1

[kill this account]

*** Bug 82076 has been marked as a duplicate of this bug. ***

Comment 2

[Chris]

Ps, Will the latest patch file from bug 82076 moved here as well?

Comment 3

[Roy Yokoyama]

assigning to bstell

Comment 4

[kill this account]

Attachment: patch; fix bit rot

Comment 5

[kill this account]

Attachment: html; cyberbit font sizes 1-29

Comment 6

[kill this account]

Attachment: html; cyberbit font sizes 1-29 with Japanese chars

Comment 7

[R.K.Aa.]

*** Bug 104744 has been marked as a duplicate of this bug. ***

Comment 8

[Jorn Baayen]

Attachment: trivial patch to make gdkxft work with moz, still runs without gdkxft. not sure if this breaks other things though.

Comment 9

[kill this account]

Comment on attachment 53822 [details]
trivial patch to make gdkxft work with moz, still runs without gdkxft. not sure if this breaks other things though.

xft is not supported on a variety of platforms that mozilla supports

Comment 10

[Nathaniel Daw]

I recently rebuilt this patch against mozilla 0.9.5 and freetype 2.0.4 and found
that though it worked with an existing font catalog file, it was unable to
generate a new one usefully from scratch -- all fonts were marked invalid, with
no usable glyphs.

This was due to every call to nsFTLoad_Glyph in nsFontCatalogFceFromFontFile
returning an error, TT_Invalid_PPem.

This error has something to do with the requested glyph size being invalid, and
shouldn't happen as far as I can tell from the freetype documentation (since
when you create a face, you get a valid size by default, suppsedly). But at any
rate, it was easy to fix by adding FT_LOAD_NO_SCALE to the options on the call.

Does anyone else see this problem?

Comment 11

[kill this account]

Nathaniel: I'm not surprised by this. It seems that FreeType2 is
changing quite a bit between the 2.0.x releases. I suspect we may need to
static link it to workaround this.

Comment 12

[kill this account]

The time has come to discuss using/not-using Xft to access FreeType2.

As I expect that there may be a lot of discussion on this topic 
I've opened a bug to address this particular issue: 

  bug 109423: FreeType2 on Linux Mozilla with/without Xft

If you would like to participate in this please add yourself to that
bugs cc: list.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

What exactly would attachment 53822 [details] break?  Would it hurt performance?

Comment 14

[Decklin Foster]

dbaron: I've been using it for a while now without any problems. There is a
slight performance hit but it's the same as any other GTK app when switched from
regular fonts to gdkxft.

Comment 15

[kill this account]

I talked to Pavlov about this and he saig that to back out the code
as is done in attachment 53822 [details] would be a mean a large performance
impact.

Second, using XLDF to access 10646 font implies a huge performanc
penalty when searching for glyphs not in the primary font.

Comment 16

[kill this account]

Attachment: patch for gfs/src/gtk; fix bit rot (needs work)

Updated so it would compile.
There are new features this needs to be changed to use:

 1) use the new alpha blending routines (see bug 107018)

 2) use the name value DB (see bug 96768)

(I made the patch in 2 parts because the patch command has trouble with
 Makefile.in)

Comment 17

[kill this account]

Attachment: patch for mozilla dir;

use this attachment and attachment 59009 [details] [diff] [review]

Comment 18

[kill this account]

as always one needs to run autoconf after changing configure.in as is done in
attachment 59010 [details] [diff] [review]

Comment 19

[Nathaniel Daw]

> 1) use the new alpha blending routines (see bug 107018)


Isn't the whole point of using XRender that it provides hardware-accelerated
alpha blending for antialiased fonts? Wouldn't it be a significant step back to
use this (afaik) software-only alpha blending routines?

Comment 20

[kill this account]

Attachment: patch; remove reference to nsNameValuePairDB.h

same comments as attachment 59009 [details] [diff] [review]

Comment 21

[kill this account]

> Isn't the whole point of using XRender that it provides hardware-accelerated
> alpha blending for antialiased fonts? Wouldn't it be a significant step back 
> to use this (afaik) software-only alpha blending routines?

Yes, Xrender is faster *where* *available*. The client side software alpha
blending is available everywhere.

I recently learned a subtlety: while Xft does not have bloat control 
Xrender does. This removes a major detraction and I am currently evaluating 
how to integrate Xrender which I have always seen as the preferred choice
over client side blending.

minor point: Xrender uses hardware if possible else it falls back to software.
Xrender using software blending is still faster than client side blending 
since it does not need to move the text's background down to the client and 
then back up to the server every time a character (or run of characters) is
drawn. A character's alpha mask only needs to be sent up to the Xrender
extension once which keeps a copy on the server. 

another minor point: Xrender is also faster since it does not try to blend
(move) the blank pixels over the video bus which is significant since text 
tends to have a high percentage of blank pixels. Sadly, this may not matter 
for Mozilla since I note that the code seems to draw the text to an off screen
copy of the window and then blit the off screen copy to the screen. I suspect
that this "double buffering" is done to prevent flicker. I do not know if
Xrender is able to use hardware blending for off screen windows.

Comment 22

[kill this account]

Attachment: patch; mozilla dir

(the diffs are broken up since patch chokes on Makefile.in)

Comment 23

[kill this account]

Attachment: patch; mozilla/gfx/public dir

Comment 24

[kill this account]

Attachment: patch; mozilla/gfx/src dir

Comment 25

[kill this account]

Attachment: patch; mozilla/gfx/src/gtk

now uses the alpha blending routines from bug 90813
now uses the DB code from bug 96768

Comment 26

[kill this account]

the db code is already in attachment 60415 [details] [diff] [review]

Comment 27

[clkao]

Attachment: fixes build when MOZ_MATHML defined.

this fixes MOZ_MATHML=1 building, although nsFreeType::InitLibrary rejects to
do initialization with MOZ_MATHML defined. but this might be needed for the
future.

Comment 28

[kill this account]

Attachment: patch; mozilla/gfx/src dir

removed gfx/src/gtk bits

Comment 29

[kill this account]

the non Xft version is in, see bug 116147 

blizzard is working on a Xft version

hopefully we will merge the best of the 2 versions 

Comment 30

[Teruko Kobayashi]

Verified.