122032 - add pref to scale bitmap fonts displayed remotely

Status: RESOLVED WONTFIX

(Core :: Internationalization, enhancement)

Description

[Andrew Schultz]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020123  (#1)
Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.7) Gecko/20011226  (#2)

Fonts with size>6 are displayed the same as size=6 when displayed remotely. 
They display properly on my local display.  The maximum size is smaller with
lower DPI fonts.  In both cases (100DPI and 75DPI), the maximum size is at the
point where the font would be antialiased, so my fonts are never antialiased
when running remotely.

also, the same thing happens if I log in to the console on the remote machine:
machine #1 => #1:  properly sized fonts
        #1 => #2:  big fonts too small
        #2 => #1:  big fonts too small
        #2 => #2:  properly sized fonts

so this doesn't seem to be anything specific to either installation of Mozilla
or X.  

Attachments from given URL with NS_FONT_DEBUG=C to follow.

Comment 1

[Andrew Schultz]

Attachment: NS_DEBUG_FONT=C, displayed locally

Comment 2

[Andrew Schultz]

Attachment: NS_DEBUG_FONT=C, displayed remotely

largest font (size=6) is no longer scaled up to proper size

Comment 3

[Andrew Schultz]

Attachment: NS_DEBUG_FONT, displayed remotely with 75DPI fonts

all 3 sizes (5, 6 and 7) are displayed the same size, not scaled.

Comment 4

[Andrew Schultz]

After examining my own attachments more closely, it appears that the fonts are
simply not scaled.  The correct sized font is chosen, but not scaled.  Changing
description.

Comment 5

[kill this account]

Andrew, your analysis is complete correct. 

Anti-alias scaled bitmap (AASB) fonts work by using XGetImage to bring the 
background down from the X server, blend the glyphs onto the background, and 
then sending the background (now with glyphs) back to the X server using
XPutImage. Bringing down the background and then sending it back up require a 
large amount of data to be transfered between the X client and the X server.

Moving a large amount of data between the X client and the X server when the
client and server are on the same machine takes a modest amount of time as
the bandwidth is high.

Moving a large amount of data between the X client and the X server when the
client and server are on different machines can take a huge amount of time as
some network links have limited bandwidth.

Because this, code was specifically added to test to see if the X server is 
local and if so not allow AASB. See bug 112522.

Comment 6

[Andrew Schultz]

old email:
---------------------------------------------------------------------------
Brian Stell wrote:
> Andrew Schultz wrote:
> 
> I discovered that I am unable to reproduce this bug when I run Mozilla
> remotely (run on another machine and display on my workstation) because
> Mozilla does not antialias the font.  Do you know why this would be, and
> do you know a way to force it to anti-alias?


Set this pref in unix.js to true to force AASB to be used for 
all fonts.

  pref("font.scale.aa_bitmap.always", false);
------------------------------------------------------------------------

"font.scale.aa_bitmap.always" does not override the "only scale locally" (nor
should it, IMO)
this seems to be part of bug #112506

reopening and changing to RFE.

I have a working patch that adds a pref to override "only scale locally".  If an
uber-pref (like bug #112506) is preferred, one of the current prefs
(font.scale.aa_bitmap.enable ?) will get replaced.

Let me know.

Comment 7

[kill this account]

A pref for allowing remote AASB is a good idea. Maybe something like

  pref("font.scale.aa_bitmap.remotely", false);

> "font.scale.aa_bitmap.always" does not override the "only scale locally" 

I agree with this.

Are you interested in working on this? I would be glad to guide you.

Comment 8

[Andrew Schultz]

Attachment: patch to add font.scale.aa_bitmap.remotely

I attempted to model the pref setup after what is in nsFontMetricsGTK.cpp.

Comment 9

[kill this account]

The other AASB controls are here:

http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#904

Could we put them all in one place?

(Either place is okay with me. I'v been lazy and just added them to the
Gtk code but you are correct in placing it in the x11shared code.)

Comment 10

[Andrew Schultz]

Attachment: a better patch

don't printf info, free xpref in FreeGlobals, and xAABitmapScaleRemote(+ly)

Comment 11

[Andrew Schultz]

I was trying to figure out how to get it in there, but the check needs to be
done in nsXFontAAScaledBitmap::InitGlobal, and based on my limited knowledge of
c++, nsFontMetric's global variables (like gAABitmapScaleRemotely) would not be
seen by nsXFontAAScaledBitmap's functions.

Or nsFontMetric::InitGlobals would need to pass it as a variable when it makes
the call.

Comment 12

[kill this account]

I suspect you can just declare them global in nsXFontAAScaledBitmap.cpp and 
external in nsXFontAAScaledBitmap.h

Comment 13

[Roland Mainz]

Can we avoid introducing new global variables, please ?
Global variables have to be removed when we want to make the code in
gfx/src/x11shared a shared library to "share" the code between the gfx modules
(gfx, xlib, xprint), otherwise the various modules will overwrite the vars used
by other modules, causing havoc and death(=core dumps).

Comment 14

[Andrew Schultz]

The other (#3) alternative would be check for remoteness of XServer within
nsFontMetrics.cpp

Putting the pref in nsFontMetrics.cpp  and doing  #2 (passing a parameter) or #3
also allows the pref to be font-specifc (ja, ko, etc...)

Comment 15

[Andrew Schultz]

I don't think making it extern will work.  the pref can't be static and extern
at the same time.  I don't think it *needs* to be static, but making it not
static is a bit hackish (since all the other prefs are static).

Comment 16

[kill this account]

Roland: now that we have some code in the x11shared dir do you have any
thoughts on how to handle shared data?

Comment 17

[kill this account]

Roland?

Comment 18

[kill this account]

The patch looks fine to me. 

Roland is maintainng the moz 'Xlib' graphics code and I have been trying 
to keep him informed of changes the the  moz 'GTK' graphics code so he could
keep his version in sync.

As we have waited a while and not heard anything from Roland I think
we should go ahead and get this in.  

r=[e-mail]

Roland, kindly let us know if you thoughts on follow up work. Please feel
free to reopen this bug as necessary.

if you 

Comment 19

[kill this account]

this is an RFE so move target to 1.1

Comment 20

[:aceman]

What is the status of this? Has the patch landed?

Comment 21

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

Comment on attachment 66712 [details] [diff] [review]
a better patch

Requesting superreview on a 9-year-old patch to code that is no longer in the tree, from a person who has never been a superreviewer and also hasn't been involved in the project for the better part of a decade doesn't seem like it's going to lead to much happening.

Comment 22

[:aceman]

He seemed relevant at the time the patch was developed. Thanks, that is the information we needed to find out. I just wanted to check if the bug is still relevant. It seems smontagu knows the answer, thanks.