The default bug view has changed. See this FAQ.

Extremly slow editing a large amount of mixed Hebrew/English text in a textarea

RESOLVED FIXED in mozilla1.9alpha1

Status

()

Core
Layout: Text
--
major
RESOLVED FIXED
14 years ago
9 years ago

People

(Reporter: Shoshannah Forbes, Assigned: mkaply)

Tracking

(Depends on: 1 bug, {helpwanted, intl})

Trunk
mozilla1.9alpha1
PowerPC
Mac OS X
helpwanted, intl
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20030101
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20030101

When attempting to edit large text in a text area- for example, when replaying
to a forum with a quote or editing text in a wiki, the editing is extremply
slow- it litrerly texts a few seconds since I type a character until it appears
on screen. It is so slow it is unusable.

This does not happen in English only pages/forms

Reproducible: Always

Steps to Reproduce:
1. Try to edit a form with lots of mixed text. For example this wiki page:
http://mac.plonter.co.il/plonwiki/Safari?action=edit or a post in a message
board with quote of a previos user:
http://www.mozilla.org.il/board/posting.php?mode=quote&p=578


Actual Results:  
Editing is painfully slow

Expected Results:  
Should edit in the same speed as English sites
(Reporter)

Updated

14 years ago
Severity: normal → major
(Reporter)

Updated

14 years ago
Blocks: 190306
*** Bug 190306 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 2

14 years ago
This is getting slower every build, and makes blogging / editing wikis / writing
email / editing web pages with composer basiclly impossible.

any progress here?

Just see how slow this example is:
http://mac.plonter.co.il/plonwiki/Apache?action=edit
(Reporter)

Updated

14 years ago
Blocks: 152111
(Reporter)

Comment 3

14 years ago
sfraser: would you be able please to take a look at this? I saw you where
working on similar bugs, and this one is a major one for Hebrew/Arabic users.

Thanks!
(Reporter)

Updated

14 years ago
Blocks: 154625

Comment 4

14 years ago
In addition, CPU usage is more then 95%, when viewing a RTL contained Page, 
Or, when trying to edit Hebrew text fields.

Comment 5

14 years ago
Sorry, I'm not working on Mozilla much any more.

Comment 6

14 years ago
Please FIX IT I LOVE MOZILLA!

Updated

14 years ago
Depends on: 212827
(Reporter)

Comment 7

14 years ago
--> bzbarsky: can you please help?
Not really -- I'm not exactly familiar with the bidi code.  Once bug 212827
lands, I'll probably try profiling this; until that point it would just be a
waste of time.
Yeah, but 212826 seems to have helped.  The page almost keeps up with my typing...


Total hit count: 1462
Count %Total  Function Name
 47   3.2    
_ZN16nsFontMetricsGTK17GetTextDimensionsEPKtjR16nsTextDimensionsPiP21nsRenderingContextGTK
 40   2.7     uMapCode
 40   2.7     SearchTable
 33   2.3     _ZN12nsLineLayout11ReflowFrameEP8nsIFrameRjP19nsHTMLReflowMetricsRi
 32   2.2    
_ZN11nsTextFrame11MeasureTextEP14nsIPresContextRK17nsHTMLReflowStateR17nsTextTransformerP14nsILineBreakerRNS_9TextStyleERNS_14TextReflowDataE
 26   1.8     _ZNK15nsBidiPresUtils17CalculateCharTypeERiiS0_S0_S0_RhS1_
 25   1.7     _ZN14nsStyleContext12GetStyleDataE15nsStyleStructID
 24   1.6     _end

is the top of the flat profile; about 1/7 of the total time is spent in
nsBidiPresUtils::Resolve (202 of the 1462 total hits).

Shoshannah, could you retest and see how it looks for you now?
(Reporter)

Comment 10

14 years ago
I tested with the page
http://he.wikipedia.org/w/wiki.phtml?title=%D7%90%D7%A8%D7%A6%D7%95%D7%AA_%D7%94%D7%91%D7%A8%D7%99%D7%AA&action=edit
and didn't see a noticible diffrents (build id 2003073003)

How do I get the hit count?

Comment 11

14 years ago
The slowness is worse as the amount of text in the text box is larger. When you
try to edit this page,
<http://mac.plonter.co.il/plonwiki/_d7_99_d7_a9_d7_a8_d7_90_d7_9c_20_d7_a8_d7_95_d7_96_d7_a0_d7_a4_d7_9c_d7_93>
on G4 500 MHz, each letter you type causes few seconds delay and a spinning
beach ball. This is not painfully slow, it is not usable at all.

Note that on the much slower hardware - G3 266 MHz, running Linux PPC, Mozilla
runs just fine. It is not fast as Konqueror in typing, but its ok.

When you profile Mozilla, you should use different text size, because using
small texts does not show the problem. We need here 1000% improvment.

Comment 12

14 years ago
To see the problem, click the link below and try to edit the textarea.
http://mac.plonter.co.il/plonwiki/_d7_99_d7_a9_d7_a8_d7_90_d7_9c_20_d7_a8_d7_95_d7_96_d7_a0_d7_a4_d7_9c_d7_93?action=edit

Note that although usable, this is also quite slow on an 850MHz PC with WinXP Pro.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925

With IE6 I get immediate feedback and typing is fluent, but with Mozilla (Win32)
there's a noticeable delay, making it difficult to type fast.

Prog.

Comment 13

13 years ago
Created attachment 138396 [details]
A 7564 word textarea (BiDi)

The attached testcase demonstrates that this unusably-slow behavior also
happens on Mozilla/Win, it does however kick in with smaller texts on Macs.

Someone else with access to both platforms would like to test this and comment
on whether this bug is really for All Hardware and OS?

Prog.
(Reporter)

Comment 14

13 years ago
I was attepting to update a few articles today in the Hebrew wikipedia (http://he.wikipedia.org ): it 
is just unworkable.
Your testcase is the same. I get a few seconds (!) delay between when I type a character until it is 
displayed.

I am on osx 10.3.2

Comment 15

13 years ago
I checked this testcase under 1.7a/BeOS and it was completely unusable, on the
other hand the wiki page was  reasonably editable. Let's leave this as Mac-only
for now.

Prog.
(Reporter)

Updated

13 years ago
Blocks: 103669

Comment 16

13 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

As comment #15 also stated, I have no problem editing the textarea at the Wiki,
but trying to edit text on the testcase is extremely slow.
I believe OS should be changed to all, i'm on win2k at the moment.

By the way, this is my first message in bugzilla, I apologize if I missed
something :)
(Reporter)

Updated

13 years ago
Blocks: 240501
It looks as a result of our behavior on mac when rendering using ATSUI APIs (For
Hebrew and Arabic, we are always using ATSUI).

Quoting from
http://lxr.mozilla.org/aviarybranch/source/gfx/src/mac/nsUnicodeFontMappingMac.cpp#65:
"because the Mac QuickDraw BIDI support are quite different from other platform
we try not to use them and use the XP BIDI feature those text will be drawn by
*ATSUI intead one character at a time*"

The problems with "ATSUI intead one character at a time" are mentioned here:
bug 120401 comment 122
bug 121540 comment 113

Fixing "one character at a time" behavior is discussed in bug 157967.
Depends on: 157967
Keywords: helpwanted, intl
QA Contact: zach → bugs.mano
(Reporter)

Updated

11 years ago
Depends on: 121540
(Reporter)

Comment 18

11 years ago
FWIW: this bug also affects email coposition and web page editing (in Thudnerbird and N|vu as well as in Seamonkey) very badly. It seems that bug #121540 and bug #157967 are going for long-term solutions (FF2 and beyond, using Cairo...), I wonder if there is any way to have a stopgap solution for here, so us Mac users are not left with major parts of functionality in the current web broken, as it is right now?
(Reporter)

Comment 19

11 years ago
Do the latest text rendering changes for FF3 affect this?
Uri- didn't you work on some related issues?
(In reply to comment #19)
> Do the latest text rendering changes for FF3 affect this?
> Uri- didn't you work on some related issues?

I'm not sure which changes you're referring to. Cairo/Mac is still not built by default, and I haven't been able to test it.

I didn't work on any Mac-specific text rendering issues. It's possible that fixing bug 319930 and bug 329878 (which are not Mac-specific) had some effect on this, but the attached testcase is still extremely slow on latest trunk builds.
This seems to be fixed by the Cairo landing (bug 323934) - editing of the Wikipedia entry mentioned in comment #10 is now completely fluent for me, and even the attached testcase is much, much faster than it used to be.

Shoshannah, could you please verify?
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Depends on: 323934
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha

Updated

9 years ago
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: mano → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.