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

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Shoshannah Forbes]

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

Comment 1

[Mike Pinkerton (not reading bugmail)]

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

Comment 2

[Shoshannah Forbes]

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

Comment 3

[Shoshannah Forbes]

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!

Comment 4

[theDave]

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

Comment 5

[Simon Fraser [no longer active]]

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

Comment 6

[Matan Radin]

Please FIX IT I LOVE MOZILLA!

Comment 7

[Shoshannah Forbes]

--> bzbarsky: can you please help?

Comment 8

[Boris Zbarsky [:bzbarsky]]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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?

Comment 10

[Shoshannah Forbes]

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

[Nir Soffer]

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

[Prognathous]

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

[Prognathous]

Attachment: 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.

Comment 14

[Shoshannah Forbes]

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

[Prognathous]

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.

Comment 16

[Victor Antolini]

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 :)

Comment 17

[Asaf Romano (gone)]

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.

Comment 18

[Shoshannah Forbes]

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?

Comment 19

[Shoshannah Forbes]

Do the latest text rendering changes for FF3 affect this?
Uri- didn't you work on some related issues?

Comment 20

[Uri Bernstein]

(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.

Comment 21

[Uri Bernstein]

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?