bugzilla.mozilla.org/show_bug.cgi?id=26502
After doing a bit of quantifying and digging the problem is the way that we are setting the clip regions/rects on the rendering context as well as the creation overhead of nsIRenderingContext's that we create everytime we do anything. The clip region/rect setting causes the X server to do some bad things with its GC cache causing it to do an XFlush() every time we change and draw. So I am working to resolve these problems and make all of this better. I have been able to reduce the X server traffic a great deal and have ideas on reducing it even further in gfx, but some of this will require some XP changes (which should also help other platforms as the quantifying on Windows I have done points to the renderingcontext as containing the highest percentages of rendering costs) ------- Additional Comment 53 #1 From 54 chris hofmann 2000-02-03 19:15 PDT ------- add perf keyword to get on waterson's radar ------- Additional Comment 55 #2 From 56 Roland Mainz 2000-02-04 05:10 PDT ------- Q: Which side (X client, X server) does the XFlush ? What about the idea like: static int xflush_inncrement = 0; Good: - Folds many XFlush()'es together, mainly into a single XFlush() at the end Bad: - Needs more investigations like: - Is this idea the best way to kill the "XFlush() called too often" problem ? What about using try {} finally {} to solve this problem ? But the SPEED of which that "copy" of the page was made with was amazing. Instantanous, judging from how the scrollbar-slider shrunk each time, and i'm on a P120. Thought I'd mention it in case it could actually bea clue to a fix. Not only does it take ten or twenty seconds to relocate on the page, if you scroll past a few pages all of the lines run together and you get a black smear. Dolan 2000-06-12 01:55 PDT ------- 33 votes, and severity major. Does this bug cover the XPFE perf problems, or just HTML rendering? HTML seems acceptable to me, but XPFE/dialogs just plain make mozilla miserable to use on linux. On my P2/266, switching sections in preferences, for example, takes 2-3 seconds to render the new dialog. Clicking in a text input box spawns a WEBSHELL, causes flickering, and then finally activates. Just using the thing, it appears to be somewhere around half as fast as Netscape 4 now, and at some general operations, it seems to be much worse. For instance, flipping between full-screen windows when some thread is active seems to take about ten times as long. And the general redraw strategy is just all wrong, making the whole thing SEEM slower. Fully agreed about the unusable XPFE performance, though. The interface needs to be about ten times as fast before it can cease to be an embarassment. Perhaps it would be more useful to start littering bugzilla with a hundreds of separate bug reports, for each UI element and user interaction operation that's embarrassingly slow? Without knowing the details, I guess, their spped is closely related. Additionally, we can use this bug to track the remaining work (which is not worth to file a bug about). Dolan's statement about taking a few seconds to render new windows and such. Opening up a link in a new window took around 10 seconds just to create the frame using M15, and is down to about 4 with M16. I also notice that things get really sluggish in other windows when one is refreshing. For example, I have an Excite page that I have on one side of my screen with stock quotes, etc. When that refresh happens, whatever I'm doing in other windows just halts until it's complete, and it takes about 10 seconds to do so. Multithreading Mozilla isa big effort, I imagine, and in my humble opinion, not one to be taken up on just yet when stability is paramount. IMO, all our XP stuff was useless, if we don't make it run better on non-Win platforms (I'm /guessing/, Mac isn't much better). I made xul window with 100 transparent gifs and run it trought xmon. There is still wery bad things in nsViewmanage2's "doublebuffering", that creates too many GC:s. Dunno, but maybe x-server tryes to do some optimization if there is stuff in queue. This XSync is just after all is done on offscreen buffer so its good to show it anyway. There really should be flag NS_COPYBITS_USE_SOURCE_CLIP_REGION_AND_XSYNC for this, but seems that its not called with that flag elsewhere (now). Dolan 2000-08-12 01:16 PDT ------- So with all these patches coming in, my only question is, how long before we can change the subject to 'Linux rendering performance is only N% faster then windows'? Let's let this bug serve its originally intended purpose, which (I assume) is to deal with the fact that Linux performance is currently sub-optimal for a final public release, and in ways beyond just fine-tuning. Once we get to fine tuning (at the XP level), let's mark this bug FIXED! The XP toolkit is unusably slow in general, layout is slow, rendering is slow, redraws are slow, etc. Shall we open a hundred bugs on every piece that's painful to use, or just the larger areas of sluggishness? Broad, generic statements like "the product crashes," or "the performance really sucks" are NOT terribly useful. Therefore, I say let's file hundreds of new bugs on specific problems, if that's what it takes. Moreover, let's use this broad bug as a meta-bug, for tracking purposes. Please try to focus on very specific common, user-oriented operations, especially those you do a lot. For instance, typing in textareas (which leaps to mind for some reason right now), or opening new browser/mail/editor windows (one bug for each), or scrolling mail thread panes line by line or a page at a time (separate problems), or opening the bookmarks menu, or loading pages, or app startup. I think you get the idea, and most of these have already been filed, so please check first. We'll only be able to fix the worst few we can get to in the next 3 weeks, but it is important that we have these areas reported separately so we can prioritize, track the work, verify the fixes, and check for regressions. BTW, program-level reports like such-and-such a routine is slow, are nice, but will typically be triaged as very low priority unless you show how this contributes to perceived slowness for common user operations. We can't afford to spend time optimizing things that are already fast enough. Oh, and please don't morph this bug into an open tracking bug, we need it to ensure QA on the checkins that it covered. And what's more, the results are VERY much visible to the average end-user. However, I still believe this bug started off much too broad and general. Also, not only does it open the door to things like the leap-frog sillyness we encountered here, but I would imagine it also makes QA's job tougher, since they now have to verify and regression-test all the specific patches this broad bug now covers. And just what the heck do they do if they find that ONE of these patches is bad? That means they now have to re-open the whole bug, even if the others are good. I *LOVE* seeing jokes in bugs (example: DEL: 205 bug 9940 :DEL ), and I really really hope to continue seeing them.
|
http://csua.com/feed/