Closed Bug 272954 Opened 21 years ago Closed 20 years ago

Slow display of large texts paragraphs being typed in text area (e.g. gmail)

Categories

(Camino Graveyard :: Page Layout, defect, P2)

Product:
Camino Graveyard
Component:
Page Layout
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino1.0

People

(Reporter: camino, Assigned: sfraser_bugs)

References

Details

(Keywords: perf)

Attachments

(3 files, 1 obsolete file)

Annoying animated gif for testcase
11.28 KB, image/gif
Details
Testcase
1.17 KB, text/html
Details
textfield only testcase
489 bytes, text/html
Details
Whenever a user types a large text into a text area in Camino, the first vew lines will be displayed without any problems. But when more and more lines are typed (>10) within one paragraph the text will need increasingly more time to be displayed. This results in text sometimes taking seconds to be displayed. When looking at Quartz Debug it's shown that one every enter of a key the entire paragraph is repainted. Looking at the CPU usage indicates that at times it will use 40/60% CPU on an 1.25GHZ G4. Something is causing Camino to reflow/repaint too much. Some people on the forum are suggesting that it might have the same cause as Bug 268218. I'll ask them to track down the start date of the issue.
Summary: Slow display of large texts being typed in text area. → Slow display of large texts paragraphs being typed in text area.
Testcase?
I've tested builds going back as far as 10/10 through the most recently nightly. The problem appears first, in my testing, in the 11/03 nightly build. Note also that this is the first nightly build after the first posting of an 8.2 test build. Testing method: All builds tested on the same iBook (800mhz G3, 384 MB, 10.3.6). I didn't create a new profile for each build since the difference is noticeable regardless. I took each build to this forum and typed at least a dozen complete sentences to give the condition time to manifest. It should be noted that there are two separate conditions, IMO, being discussed here. One is the fact that there is some lag experienced for fast typists in most text box input. I see this on most browsers on my laptop. It's just barely noticeable, but can easily be conjured up by rapidly hitting a string of letters. I don't think this is a Camino issue, per se. The other problem, and the one I was testing for, was a very pronounced and progressive slow down when typing several sentences. It is noticeable even when typing slowly and eventually each character is 'blinking' when typed until things get to where the display simply won't keep up any longer. This condition first appears in the 11/03 nightly build, in my testing. If someone else would like to verify by testing the 11/01 and 11/03 builds, that would be another data point. Two other details I verified while testing. I noted the jerky scrolling issue to see if it and the typing delay were related (at least by build). But scrolling is ok in both the 11/01 and 11/03 builds. I also pulled the latest Java embedding plugin and tested the problem builds again to make sure it wasn't getting in the way somehow.
Kevin: i bet your iBook is thrashing. Buy more memory ;)
K Simon, I wasn't able to really see this bug untill I looked into it closely. I have a 1.25Ghz G4 with 1gb of ram, no problem there. I noticed the lag of text entered only in the following situation. 1) Take any text area, having many tabs open or having lot's of animated gif only enlarges the issue. 2) Start typing and make sure you do it fast. I just typed non-sence. Don't hit eneter, just keep on typing. Whenever you have more then 10 lines of text you will start noticing the text typed is delayed while painted. 3) the more lines are present and the more words you type, the longer the delay will be in the text shown. I have only been able to see this while really typing very very fast but at some point you will see the issue appear. The most astoniching is that Camino is taking more cpu to type in text than it needs to render an entire webpage. Camino is doing some serious repainting while I see no reason for it to do so. That is also why having opened many tabs or having a page with heavy content will show the issues very fast.
Keywords: perf
(In reply to comment #3) > Kevin: i bet your iBook is thrashing. Buy more memory ;) Ha! Yes, it's already ordered. Makes using NeoOffice/J a drag too. ;-)
I'll confirm Kevin's diagnosis of 11-03 as the breaking point on this one. (Even this one sentence in Bugzilla is relatively crawling in the 11-03 0.8+ NB!) I just spent the afternoon typing away in text boxes in the 11-01 and 11-03 builds (there was no 11-02 trunk NB). I did notice the slow typing a *tiny* bit in the 11-01 build (now that I know what I'm looking for)--and I swear there's a long-standing bug in Bugzilla on slow typing, but I can't find it now. The 11-01 build also fails the "fast typing of gibberish test", but not to the extent of the 11-03, and in general typing in the 11-01 build behaves fast enough not to notice anything on a relatively fast/recent Mac (PB G4 1.33 GHz, 512 MB, 10.3.6). But the slow typing *absolutely* becomes greatly exacerbated in the 11-03 build, to the point that people who had never noticed it before (like me from July-Oct) notice it now! (Wow, I just got up to 100% CPU typing those last couple of words!) Hope this helps.
Do you folks know why typing might have got more CPU-hungry in the 11/03 build?
Only checkin I see that could perhaps have done something is Bug 267040.
So was this OK in a Nov 2 build? Or are there no such builds, per comment 6? What are the actual timestamps of the last good and first bad build?
(In reply to comment #9) > So was this OK in a Nov 2 build? Or are there no such builds, per comment 6? > What are the actual timestamps of the last good and first bad build? I still think the pre-November 3 build slow typing is different from the problem that was introduced in the Nov 3 build and later. Pre Nov 3, slow typing was minor (many probably don't even notice it) and consistent throughout all typing. Probably dependant on client machine specifications. Post Nov 3, it has a different feel (the flashing with each character) that starts minor but quickly progresses as more words are keyed in. It gets to the point that typing becomes almost impossible to continue. The problem is still just as bad in the latest (12/19) build.
(In reply to comment #9) > So was this OK in a Nov 2 build? Or are there no such builds, per comment 6? > What are the actual timestamps of the last good and first bad build? According to the listings at http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ there was no trunk nightly for Nov 2, only a 0.8.2 branch nightly/RC. The timestamps: server Camino.dmg Camino.app 01-Nov-2004 15:17 17:17 (EST) 14:58 (EST) (last good build) 03-Nov-2004 14:45 16:45 (EST) 14:35 (EST) (first bad build) I have no idea what timezone the ftp.mozilla.org server is in, and the other two timestamps are from the Finder's Get Info on the respective files (I'm in EST/GMT -5); if there's another place I should be looking for a more official timestamp, let me know and I'll track it down--this bug's starting to get annoying again :)
OK. So the possible cuplrits in that date range look like: Bug 265165, bug 243726, bug 266890, bug 266968. Can someone with a mac build who's seeing this bug and can build try adding these patches one by one to a Nov 1 build and seeing which one causes trouble?
I looked at Firefox and it does have the same issue, but it seems it's just rendering/updating much faster then Camino. Looking at what happens with Quartz Debug show that Camino is indeed redrawing the entire paragraph when ever a new key is pressed (identical redraw shown i red). So when you have a long paragraph redrawing get's slower every time you add a letter/numbre. Starting a new paragraph then solve sthe issue but get's worse when that get's longer aswell. Firefox displays the exact same behaviour. Could somebody explain why we are redrawing the entire paragraph when all we need to do is redraw a new line?
> Could somebody explain why we are redrawing the entire paragraph when all we > need to do is redraw a new line? Good question. Put a breakpoint in nsFrame::Invalidate() and see what's up?
I'm having the same issue, but noticing that if there are multiple animated gifs, not only does the typing slow down the machine to a crawl, but if there is a text box and animated gifs, even scrolling is bogged down. I frequent a phpbb forum where the text box has about 18 emoticon animated gifs next to it. The moment I start to type, I'm waiting literally seconds for the text to appear. On an 867MHz g4 powerbook with 640MB ram using the latest nightly. This does not affect me under Firefox or Mozilla.
*** Bug 286295 has been marked as a duplicate of this bug. ***
Same as comment #15. Here's the same page, but on the 2nd, all the animated gifs have been commented out: http://pub.abuserz.com/test_camino.html http://pub.abuserz.com/test_camino_2.html Entering some text in the "Enter your Post" textarea: - Using Camino 2005031908: very slow on test_camino.html, almost fast on test_camino_2.html - Using Firefox 1.0: fast on test_camino.html and test_camino_2.html, even if test_camino.html use a lot of CPU.
I really think a serious look has to bedone for this bug. This is a big show stopper for all of use using forums on a regular base.
Flags: camino0.9?
Then you can add your vote to it ("Vote for this bug" link at the top). The more vote it has, the faster it will be looked into.
Haha yeah right :)
If people want this to be fixed, then someone who HAS A MAC needs to look into it. Now I don't have a Mac, but I'm willing to help walk people through debugging this if they're willing to put their time where their mouths are. My attempt to do that in comment 14 was completely ignored in favor of further ranting, though. Given that, I'm unccing myself from this bug. If someone who has a Mac decides to actually try to do something about this, please re-cc me; in the meantime I can avoid all the spam.
Marking this as an 0.9 blocker. We should at least look into fixing it again, and we should take advantage of bz's willingness to help. Will re-cc him when we get to actively looking at it again.
Flags: camino0.9? → camino0.9+
Target Milestone: --- → Camino0.9
This seems to be a pathological combination of Cocoa coalescing update rects (bug 280982) and the caret-animated GIF redraw bug 54153. It's much better in Firefox, which makes me think that the best approach is to see if we can prevent Cocoa from over-drawing.
Assignee: pinkerton → sfraser_bugs
Depends on: 280982
Attached file Testcase (obsolete) —
Attachment #178873 - Attachment description: Annoying animatd gif for testcase → Annoying animated gif for testcase
Attached file Testcase —
Attachment #178874 - Attachment is obsolete: true
The patch in bug 54153 is going to help an awful lot here. Commenting out the lines that hide and show the caret in PresShell's nsICompositeListener make a huge difference.
Status: NEW → ASSIGNED
Depends on: 54153
Unfortunately that patch is years old and kin almost completely inactive. However, the "paint caret via frames" work would address this problem since we'd no longer have to explicitly hide/show the caret when painting...
Part of the reason that this is so painful on Mac is that nsRenderingContextMac::FlushRect() does a synchronous flush of the back buffer to the screen with QDFlushPortBuffer(). I tried replacing this with a call to QDAddRegionToDirtyRegion(), but that doesn't work (probably not supported with NSQuickDrawView). We might need to invalidate via the widget.
*** Bug 287609 has been marked as a duplicate of this bug. ***
Invalidating via the widget doesn't seem to work either, possibly because it doesn't play nicely with InvertRect(). The caret never blinks.
Priority: -- → P2
(In reply to comment #23) > This seems to be a pathological combination of Cocoa coalescing update rects > (bug 280982) and the caret-animated GIF redraw bug 54153. I don't understand the technical details, but both of those bugs look like they're dealing with animated GIFs, and I just wanted to make sure we didn't forget that this bug was begun with cases not involving animated GIFs (comment 0, comment 13, comment 2)--Bugzilla, as we know, has no animated GIFs by its textboxes :-) Apologies for the noise.
As I noted in the initial report, animated gifs or page that have heavy cpu content only help to show the actual slow typing. The fact is that slow typing also happens when non of the animated gifs or flash movies are on the page.
Attached file textfield only testcase —
Testcase that will allow to see the slow typing in just a text area.
*** Bug 289658 has been marked as a duplicate of this bug. ***
Aperantly this has gotton even worse the it was over the last 2 weeks. What the heel is going on here?
Jasper, also see core bug 289022. These bugs are all so closely related that we may be seeing comments posted to the wrong bug (I know because I did it).
*** Bug 293481 has been marked as a duplicate of this bug. ***
(In reply to comment #37) > Jasper, also see core bug 289022. These bugs are all so closely related that we > may be seeing comments posted to the wrong bug (I know because I did it). For what it is worth to those working on this bug, I experience only at 1 of the several forums I post at: http://www.techsurvivors.net. As soon as I click in the text box of the Post or Reply Form, the cursor starts blinking too fast to count and typing is painfully slow. It happens immediately, as soon as I click in a text box and is unrelated to amount or speed of typing. It has been present with versions 0.8.2 through 0.8.4 and with OS X 10.3.8 through 10.4. I do not experience the bug at MacFixit Forums, Apple Support Forums, or any other Forum.
Problem solved by use of a suggestion made at TechSurvivors. I used the ExtraPref and changed the Animation Mode from "None" to "1" and typing problem disappeared. Is this a clue as to nature of bug and possible solution?
In case someone else didn't recognize it, he means http://support.meer.net/spam/b.php?c=s&i=214414&m=dd57da22056b On the display page, I changed animation mode from "normal" to "once" per his suggestion and tried a few forums. It is definitely faster, but not fast. It's roughly 1/10th the speed of typing in these text boxes on Firefox, instead of 1/100th. I can still out-type it by a sentence or two in a long paragraph.
As I've said above, this is just more evidence that many cases of slow typing are the animaged gif/caret problem, which is bug 54153.
*** Bug 296079 has been marked as a duplicate of this bug. ***
*** Bug 296532 has been marked as a duplicate of this bug. ***
The latest Nightly seems to be much better handling forums with animated GIFs. I'm running 2005061708 (0.9a1) and I didn't notice any slowdown when posting on Neowin.net
It doesn't seem any better to me (try the Testcase).
*** Bug 298476 has been marked as a duplicate of this bug. ***
(In reply to comment #46) > It doesn't seem any better to me (try the Testcase). I agree with you. I have CamiOptions (used to be ExtraPrefs) and have animated GIFs turned off. The more I type into the text box, the slower it gets. Same thing happens to me on pages with no animated GIFs at all. (Like right here in this text box as I'm typing this on Bugzilla.) I'm using the 6/28/05 nightly right now on a G4 667 Powerbook. Having animated GIFs on the screen at the same time compunds the issue by taking up additional CPU cycles but it is not directly related. I noticed this listed as a known issue in the release notes. I noticed that as soon as you have a CR/LF in the box, the speed starts back like the box was empty until you get more chars into a paragraph. Seems to be on a paragraph by paragraph basis instead of total number of CHARS in a box. I also noticed that it gets WAY slower by inserting typing in the middle of a line (causing the following text to shift forward) instead of typing at the end of the line.
I forgot to add that saw a request for testers. I'd be totally willing to do some testing but I'd need to be walked through what is needed. I have no experience with applying patches but can follow directions well. Contact me if you need me. I have a great interest in seeing this issue fixed.
I think we're all missing the original point; we're talking about lag of typing in general over time with paragraphs due to redrawing, not due to animated GIFs. It's given this will make the original bug worse, however, I think we need to worry more about the original bug (sans the animated GIFs) rather with. I have an iBook G4 800Mhz 640 MB Ram, and I get the typing lag pretty much everywhere when I type a lot (Gmail, mainly.) using the NB from 06/20.
Summary: Slow display of large texts paragraphs being typed in text area. → Slow display of large texts paragraphs being typed in text area (e.g. gmail)
Notes on gmail typing perf in Camino. I typed a long paragraph in gmail compose, and profiled with Shark. I note that QuartzDebug shows us redrawing the entire paragraph for each character typed. 4.8% of the time is spent filling rects (bug 34887) 4.4% of the time is spent in objc_msgSend, mostly in methods relating to view drawing 3.9% is spent in __spin_unlock, coming out of thread locking, malloc/calloc etc. 2.5% is in text rendering 2.2% is in getting pthread globals 1.9% is in kernel stuff. ... some more pthread mutex and objc_msgSend stuff 1.3% is in nsUnicodeFontMappingMac::GetFontID() (which does sucky linear search) 1.3% is in __spin_lock 1.1% is in free() That's about 27% of the time. The rest is a long list of nickel-and-diming, though it's notable that several near the top are in the View Manager.
Same problem here. I'm running the 2005062408 (0.9a1+) version on a new PB 17" 1,67Ghz, 1Gb RAM. I already moved Firefox and Safari to a "deprecated" folder until I tried to reply to emails in gmail... it's really frustrating, specially 'cos, well, how many emails you send EVERY DAY? What should I do? Use camino and then switch to Firefox or Safari whenever I want to write an email? Since the Milestone is way back, couldn't you please update it? I'd really love to stay on Camino, it beats any other browser by far... unless you write an email. Thanx
More notes on typing perf on gmail. For each character typed, the views draw back to front (because they are non-opaque), and there are 7 nested views there. For each of those, we can make multiple calls into Gecko, because of code in [ChildView drawRect:] which calls -getRectsBeingDrawn:count:. So we end up making tens of mGeckoChild->UpdateWidget() calls. We could do some coalescing, but we'd have to not regression bug 222972.
Depends on: 300797
*** Bug 300727 has been marked as a duplicate of this bug. ***
The patch in bug 166932 helps here.
This is good enough after the fix from bug 166932 that I'm moving it out.
Severity: major → normal
Target Milestone: Camino0.9 → Camino1.0
Uh, why exactly do you feel that this is no longer important? Camino remains unusable for any sort of forum or web e-mail usage. Or is there a patch that isn't in the nightly builds yet?
I don't feel that it's not important. I just think that builds after 7/16 are significantly better, and there is nothing more we can do until we move to a Quartz gfx.
*** Bug 301481 has been marked as a duplicate of this bug. ***
(In reply to comment #58) > I don't feel that it's not important. I just think that builds after 7/16 are > significantly better, and there is nothing more we can do until we move to a > Quartz gfx. Hello. I tested July 20 build of the Camino. It is still very slow to write in Korean. Is the Camino moving to Quartz? Wasn't it already Quartz-based? So do you guys want to solve this problem after moving to Quartz?
(In reply to comment #58) > I don't feel that it's not important. I just think that builds after 7/16 are > significantly better, and there is nothing more we can do until we move to a > Quartz gfx. Ok, this is fixed for straightforward text editing, but if you check the test case, it's still NOT usable for discussion forums that use animated gifs like phpBB. It's a showstopper for ME, which is all I care about ;) . It also is something that suddenly appeared in the 11/03 build, and does not appear in mozilla or firefox, so I don't know why it's unfixable at this point? Sorry if I sound whiny, but I really liked using Camino, and I can't until this is fixed. I really do appreciate the hard work put into it, and I can accept that there are other priorities, but Waaaah :( <=== me acting like a baby.
Keep in mind bug 280982 is still open and has bearing on this.
(In reply to comment #61) > (In reply to comment #58) > It also is something that suddenly appeared in the 11/03 build 20050311? What is the last build before that that doesn't show the problem?
(In reply to comment #63) > (In reply to comment #61) > > (In reply to comment #58) > > > It also is something that suddenly appeared in the 11/03 build > > 20050311? What is the last build before that that doesn't show the problem? See Comment #2 - That would november 3rd, 2004.
This is the only thing that might be relevant: bug 243726.
Attempting to enter a single character in a new message on this message board: http://www.badastronomy.com/phpBB/index.php took close to a minute. This is with v0.9a2 and is a significant deterioration from already poor performance in previous versions (when it took only a second or two, which was already way too slow).
(In reply to comment #67) > Attempting to enter a single character in a new message on this message board: > > http://www.badastronomy.com/phpBB/index.php > > took close to a minute. This is with v0.9a2 and is a significant deterioration > from already poor performance in previous versions (when it took only a second > or two, which was already way too slow). Typing speed is quite acceptable for me on http://www.badastronomy.com/phpBB/posting.php?mode=newtopic&f=2 in a recent build. What is your hardware, and how much memory do you have?
My experience: Building Camino with gcc 3.3 default SDK (10.2.8) with any optimization flags results in a stable and this-bug free build. Building Camino with gcc 4.0 and SDK 10.4u with any optimization flags results in a faster (placebo effect, perhaps) build with the forms-typing bug Static build, both of em Generally I use -mcpu=G5 -mtune=G5 -O3 as optimization flags, but in rencently builds -O3 flag result in a make error and I had no time to look out why. With gcc4 I use -ftree-vectorize too I think this bug is caused for something in SDK 10.4u because it is mandatory to use it when build with gcc4 Xcode 2.1 version. Maybe I'm wrong... I hope this may help
(In reply to comment #69) > My experience: > Building Camino with gcc 3.3 default SDK (10.2.8) with any optimization flags results in a stable and > this-bug free build. > Building Camino with gcc 4.0 and SDK 10.4u with any optimization flags results in a faster (placebo > effect, perhaps) build with the forms-typing bug Are you building both from the same source tree? Perhaps the trees are different dates? I checked in a fix for bug 280982. Please test the release build 20050722.
In the spirit of hitting a moving target, I upgraded my laptop today, and that along with your patch has made forums usable again with Camino. Simon, you rock! I'll double check with my old laptop tomorrow to let you know if we have a complete fix.
(In reply to comment #70) > Are you building both from the same source tree? Perhaps the trees are different > dates? > > I checked in a fix for bug 280982. Please test the release build 20050722. Yes, I building from same tree (20050719)... Let me read the entire deps of this bug, checkout the source and test it
Based on reports, I'm marking this fixed. I think the biggest remaining issue here now is bug 54153.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050722 Camino/0.9a2+ GCC 4 -mcpu=G5 -mtune=G5 -ftree-vectorize -O2 (SDK 10.4u - static) this bug persist, the more animated the page and the more you write the more you get a BIG delay writing in forms. With no animations the bug is barely noticeable, just a very little delay. I'm building GCC3 version right now, but I think the result will be the same --> GCC4 bugged, GCC3 bug free. Still thinking the same thing: something about SDK and/or GCC4 may cause this behavior I am doing some extra research right now and a more "plain" set of builds (no optimizations at all) to see if this bug is SDK's, gcc's or optimization flags caused. This is all I can do for Camino's community cause I'm not hacker, my 2 cents
(In reply to comment #74) I noticed the same slow text drawing problems with my GCC 4.0.0 and 10.4u SDK build today. Posted as bug 301774 before I saw this post. From what I have tested it seems to be an issue between the bug 280982 checkin and 10.4u SDK. Since it worked fine in a GCC 4.0.0/10.3.9 SDK build I just tested.
Hi. Well.. I found something interesting. Today's build of Thunderbird, ie. July 24 , has the same problem. There is no noticeable flickering while you are typing email message, but it is very slow. A few days ago, there is no such problem. I didn't add any images in email message. The default style was HTML. Interestingly, the Thunderbird version has some drawing problem. Its Format menu is drawn twice or omitted sometimes. Maybe this redrawing problem is in the core.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: