Closed Bug 188294 Opened 17 years ago Closed 13 years ago
Extremly slow editing a large amount of mixed Hebrew/English text in a textarea
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
*** Bug 190306 has been marked as a duplicate of this bug. ***
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
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!
In addition, CPU usage is more then 95%, when viewing a RTL contained Page, Or, when trying to edit Hebrew text fields.
Sorry, I'm not working on Mozilla much any more.
Please FIX IT I LOVE MOZILLA!
--> 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?
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?
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.
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.
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.
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
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.
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 :)
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.
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?
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
Closed: 13 years ago
Depends on: 323934
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
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.