If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

add pref to scale bitmap fonts displayed remotely




16 years ago
7 years ago


(Reporter: Andrew Schultz, Assigned: kill this account)




Firefox Tracking Flags

(Not tracked)




(5 attachments)



16 years ago
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

16 years ago
Created attachment 66624 [details]
NS_DEBUG_FONT=C, displayed locally

Comment 2

16 years ago
Created attachment 66625 [details]
NS_DEBUG_FONT=C, displayed remotely

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

Comment 3

16 years ago
Created attachment 66626 [details]
NS_DEBUG_FONT, displayed remotely with 75DPI fonts

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

Comment 4

16 years ago
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
Summary: big fonts are smaller when displayed remotely (Xwindows) → bitmap fonts are not scaled when displayed remotely (Xwindows)

Comment 5

16 years ago
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.

Last Resolved: 16 years ago
Resolution: --- → INVALID

Comment 6

16 years ago
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.
Severity: minor → enhancement
Resolution: INVALID → ---
Summary: bitmap fonts are not scaled when displayed remotely (Xwindows) → add pref to scale bitmap fonts displayed remotely

Comment 7

16 years ago
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.
Ever confirmed: true

Comment 8

16 years ago
Created attachment 66710 [details] [diff] [review]
patch to add font.scale.aa_bitmap.remotely

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

Comment 9

16 years ago
The other AASB controls are here:


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

16 years ago
Created attachment 66712 [details] [diff] [review]
a better patch

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

Comment 11

16 years ago
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

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

Comment 13

16 years ago
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

16 years ago
The other (#3) alternative would be check for remoteness of XServer within

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

16 years ago
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

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


16 years ago
Keywords: intl
QA Contact: ruixu → ylong

Comment 17

16 years ago

Comment 18

16 years ago
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.  


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

16 years ago
this is an RFE so move target to 1.1
Target Milestone: --- → mozilla1.1
QA Contact: amyy → i18n

Comment 20

7 years ago
What is the status of this? Has the patch landed?


7 years ago
Attachment #66712 - Flags: superreview?(roland.mainz)
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.
Attachment #66712 - Flags: superreview?(roland.mainz)
Last Resolved: 16 years ago7 years ago
Resolution: --- → WONTFIX

Comment 22

7 years ago
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.
You need to log in before you can comment on or make changes to this bug.