HP-UX font rendering is very slow

RESOLVED INCOMPLETE

Status

P3
normal
RESOLVED INCOMPLETE
18 years ago
6 years ago

People

(Reporter: jimmyu, Assigned: martinlawyer)

Tracking

Trunk
Future
HP
HP-UX

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
This is a HP only bug.

This problem are only reproducible from a local machine. When running the
browser with the HP Java Plugins 1.3 the fonts are whacky (especially noticeable
at www.go.com). After exit out the browser this process doesn't go away, even if
you logoff the machine. To see the process do the following from the command prompt:
ps -ef|grep xfs

it will display:
/usr/bin/X11/xfs -config /etc/X11/fs/config -port 7000 -daem

This is the same problem with Communicator 4.76 and HP Java Plugins 1.2.2.04
(and higher) refer to bugsplat#518078.
(Reporter)

Comment 1

18 years ago
Update QA to myself and add block 18688
Blocks: 18688
QA Contact: geetha.vaidyanaathan → jimmyu
(Reporter)

Comment 2

18 years ago
reassign bug to shannond also correct blocks
Assignee: jgaunt → shannond
Blocks: 18687
No longer blocks: 18688

Comment 3

18 years ago
I see this too.  After running the browser with the Java Plugin installed, the
process that Jimmy mentioned above is now present.  It causes fonts on some
pages to become larger and bold looking.  After trying to kill this process,
since it isn't terminated when the browser is exitted, trying to restart the
browser is VERY slow.

I also tried killing this process the correct way:  In /etc/rc.config.d/xfs set
RUN_X_FONT_SERVER variable to 0  (mine was already at zero) then running the
command:  /sbin/init.d/xfs stop

This also had the same effect on the browser - startup was extremely slow.
(Reporter)

Comment 4

18 years ago
assign bug to shannond

Comment 5

18 years ago
Marking NEW as per comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

18 years ago
moving to oji
Assignee: shannond → edburns
Component: Java-Implemented Plugins → OJI

Comment 7

18 years ago
reassign.
Assignee: edburns → James.Melvin

Comment 8

18 years ago
CC to brian stell.
The problem why bold font got used in browser is because we are treating all 
fonts with unidentified name in weight field as regular font. When running xfs,
it return us a font whose weight field is "black". This font got used for 
aria font family.

(Reporter)

Comment 9

18 years ago
re-assign bug to shanjian as per comment
Assignee: James.Melvin → shanjian
No longer blocks: 18687
Severity: normal → blocker
Component: OJI → ActiveX Wrapper
OS: HP-UX → All
QA Contact: jimmyu
Hardware: HP → All
Summary: HP Java Plugin 1.3 causes the system to spawn a runaway process
Target Milestone: --- → M1
(Reporter)

Comment 10

18 years ago
sorry, somehow my last update deleted the summary and changed the platform settings.
Severity: blocker → normal
Component: ActiveX Wrapper → OJI
OS: All → HP-UX
Priority: -- → P3
QA Contact: jimmyu
Hardware: All → HP
Summary: HP Java Plugin 1.3 causes the sytem to spawn a runaway process

Comment 11

18 years ago
CC to brian stell.
The problem why bold font got used in browser is because we are treating all 
fonts with unidentified name in weight field as regular font. When running xfs,
it return us a font whose weight field is "black". This font got used for 
aria font family.

Blocks: 18687
Priority: P3 → --
Summary: HP Java Plugin 1.3 causes the sytem to spawn a runaway process → HP Java Plugin 1.3 causes the system to spawn a runaway process
Target Milestone: M1 → ---

Comment 12

18 years ago
I talked with brian about the problem, and he kindly accepted this bug. I 
will reassign it to brian. Jimmy, please 
Assignee: shanjian → bstell

Comment 13

18 years ago
Let me see if I understand this bug:

    start mozilla 6
    go to www.go.com
    www.go.com loads a plugin
    the plugin somehow causes moz6 to ask for a font
    moz6 asks the X server for the font
    the X server asks xfs (X Font Server) for the font
    xfs uses alot of CPU cycles; possibly in an infinite loop

Is this right?
(Reporter)

Comment 14

18 years ago
Steps to reproduce:
1) login locally on a HP machine
2) install HP Java Plugin 1.3 or higher
3) start N6

Results: font size appears to be larger than normal

Expect result: normal font size


The HP Java Plugin spawns a xfs process when user is running from a local
machine. And this xfs causes the default N6 font to appear larger.


Attach email from the HP Java Lab people:
+++++++++++++++++++++++++++++++++++ START ++++++++++++++++++++++++++++++++++++++
Subject:
[Fwd: xfs/Netscape problem...]
From:
jaworski@netscape.com (Rob Jaworski)
Date:
Thu, 03 May 2001 14:57:59 -0700
To:
Shanjian Li <shanjian@netscape.com>

You might want to deal with George and Bino directly on this...

-------- Original Message --------
Subject: xfs/Netscape problem...
Date: Wed, 02 May 2001 20:09:48 -0700
From: "George Cross,42U,(619)497-0926" <gcross@cup.hp.com>
To: walter_lamia@hp.com,   "MCDONALD,MARY (HP-Cupertino,ex1)"
<Mary_mcdonald@hp.com>,   Kit Chatsinchai <kit@cup.hp.com>, kishan@cup.hp.com,
binog@cup.hp.com,   jaworski@netscape.com

Dear Walt, Rob,

This is in regard to the problem whereby the HP-UX jvm starts the X Font
Server (xfs) and this causes Netscape to display a bold font where it
would normally display a medium font if xfs were not running.

Bino did some investigation into the source code for Mozilla and found a
couple of things:

1. On Linux, if one were to start xfs (albeit not indirectly through the
jvm) the same problem appears.
2. If we specify a medium weight as the first matched font within a
family, then we get the same fonts as when xfs isn't running.

Specifically, in the file, gfx/src/gtk/nsFontMetrics.cpp, in the
function FindFamily() around line 2822, if the pattern is set to

   *-%s-regular-*-*-*-*-*-*-*-*-*-*-*-*

instead of

    *-%s-*-*-*-*-*-*-*-*-*-*-*-*-*

Then we see the correct font displayed.

One solution would be to request a medium weighting, and if in the
unlikely case it is not matched, then revert to the first listed font
within the family.  I will forward a short snippet of code which will do
this within the next few days, for whomever's perusal.

For Walt, this is in Chart, JAGab84768.

Thank you all very much.  Please kindly let me know if there is anything
else I can do to help move this issue closer to resolution.

Sincerely, George
++++++++++++++++++++++++++++++++++++ END +++++++++++++++++++++++++++++++++++++++

Comment 15

18 years ago
There are 2 very separate issues here:

 1) HP-UX font rendering uses "alot" of CPU cycles

 2) the font weight of "black" should be aliased to "bold"
    I have opened a bug for aliasing a weight of black: 
    http://bugzilla.mozilla.org/show_bug.cgi?id=80359

The solution to #1 is <b>NOT</b> modify Mozilla's font system 
to avoid fonts with a weight of "black". This also does not seem to 
be a plugin issue.
Assignee: bstell → jdunn
Summary: HP Java Plugin 1.3 causes the system to spawn a runaway process → HP-UX font rendering is very slow

Comment 16

18 years ago
Jim: we're going through a triage pass of OJI bugs and prioritizing and making 
sure all bugs are assigned.  Will you please accept this bug or close it as 
not-an-OJI-bug?  If you accept, will you please assign a priority for this bug?
Thank you in advance, sir; it's a pleasure doing business with you.

Comment 17

18 years ago
moving this past the next release...
if someone has a fix, let me know, we can try to get
it in.  I just don't have one right now and want to
keep the books clean.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.0.1

Comment 18

18 years ago
Since the HP-UP X server has a issues with scaled fonts we should probably query 
the server and if it is an HP server then set a flag never to ask for scaled 
fonts.

Comment 19

16 years ago
re-assigning to Martin.
My guess is this isn't important but will let him decide
Assignee: jdunn → martinl
Status: ASSIGNED → NEW

Comment 20

15 years ago
retargeting
Target Milestone: mozilla1.0.1 → Future
Is this still an issue ?

Updated

8 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
QA Contact: jimmyu → java.oji

Comment 22

6 years ago
Mass-closing bugs in the "OJI" component: OJI plugin integration was replaced with npruntime long ago, and these bugs appear to be irrelevant now. If there is in fact a real bug that remains, please file it new in the "Core" product, component "Plug-ins".
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.