Closed Bug 26502 Opened 25 years ago Closed 24 years ago

Linux rendering performance is slower than windows.

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: pavlov, Assigned: pavlov)

References

Details

(Keywords: perf, platform-parity, Whiteboard: [nsbeta3+])

Attachments

(8 files)

patch to avoid an XSetFont for each text draw we do
5.25 KB, patch
Details | Diff | Splinter Review
new patch.. ignore the previous one
6.89 KB, patch
Details | Diff | Splinter Review
patch to nsImageGTK to reduce the number of creategc/freegc calls
2.80 KB, patch
Details | Diff | Splinter Review
more fun image patch.. is resizing pixmaps legal? :-)
5.56 KB, patch
Details | Diff | Splinter Review
patch for nsGCCache to reuse gcs
5.71 KB, patch
Details | Diff | Splinter Review
patch #2 for GCCache, uses XChangeGC
6.37 KB, patch
Details | Diff | Splinter Review
imot's gc cache patch cleanedup a lil
5.87 KB, patch
Details | Diff | Splinter Review
check if all other but clipregion matches in GCcache
2.63 KB, patch
Details | Diff | Splinter Review 
Linux scrolling and rendering are both very slow.  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.  yeah, this sucks. 
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)
Status: NEW → ASSIGNED
Keywords: beta1, pp
Priority: P3 → P1
Summary: [PP] Linux rendering performance is at least 5x slower than windows. → Linux rendering performance is at least 5x slower than windows.
Target Milestone: M14
add perf keyword to get on waterson's radar
Keywords: perf
Blocks: 12761, 16710, 25811
Summary: Linux rendering performance is at least 5x slower than windows. → Linux rendering performance is MUCH slower than windows.
No longer blocks: 16710
Q: Which side (X client, X server) does the XFlush ?

What about the idea like:
static int xflush_inncrement = 0;

syncronized void EnterNestedXFlush()
{
    xflush_inncrement++;
}

syncronized void LeaveNestedXFlush()
{
    xflush_inncrement--;
    if( xflush_inncrement <= 0 )
    {
      XFlush();
    }
}


The idea is that a component calles EnterNestedXFlush() when beginning a
modification (drawing etc.) and calls LeaveNestedXFlush() if the modification is
done - XFlush() is then only called if it is fully done, e.g. the "last"
LeaveNestedXFlush() as been called.

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 ?
  - Is this thread safe ?
  - Is there a way to avoid that unmatched calls to *NestedXFlush() kills this
optimisation ? What about using try {} finally {} to solve this problem ?
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Blocks: 25824
the client does the flush, but it is in the xlib code, which we can't change and
have no control over it.
Whiteboard: [PDT+] → [PDT+] Should be able to remove beta1 around 02/15/19100.
Removing PDT+ and beta1.  I find performance acceptable for a beta.
Keywords: beta1
Summary: Linux rendering performance is MUCH slower than windows. → Linux rendering performance is slower than windows.
Whiteboard: [PDT+] Should be able to remove beta1 around 02/15/19100.
The summary should be changed from "Linux rendering performance is slower than 
windows" to just "slow" (or maybe "much slower", if that's accurate) because 
there's nothing inherently wrong with something running faster on windows.
sure there is.  linux should be faster. :-)
Time to bring out the flame guns :)
Windows is always going to be faster, kids.
fuck off ramiro ;)
This might be related to bug #20242, please see for example the following URL:
http://www.linux-mandrake.com/lothar/news.html
Severity: critical → major
Priority: P1 → P2
Target Milestone: M14 → M15
"Sorry for intruding"... but as all know, mozilla is also a great deal slower
than netscape 4.7 under linux, what page-rendering is concerned. (Scrolling
works fine now btw, cept in ftp) But i stumbled across a strange bug reported in
31986. Bug was gone in the next build so i set it invalid. 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. In other
words no rendering prob's. Thought I'd mention it in case it could actually be a
clue to a fix.
The scrolling isn't fine now; it's at least a factor of 2 slower than
Netscape 4.7 (and probably a factor of 4 slower than the opera beta) on simple
pages.

On complex pages such as www.cnn.com or the tinderbox page, scrolling degrades
very rapidly.  (Probably due to the rendering speed).
*** Bug 32491 has been marked as a duplicate of this bug. ***
I don't have a problem with CNN on a PII450, but try some of the Gutenberg
E-Texts -- It can take seven or eight minutes to render a few hundred K of text.

And scrolling - ugh! 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.


not sure if this is related to rendering on linux in general or something else..
try this: query all bugs from bugzilla, you get a page over 2000k in size. then
scroll by dragging the vertical scrollbar fast up and down.

when doing it slow, it's just a little sluggish but doing it faster, you get
about 1second delay before the page is drawn (on k7/600), and the page gets
sometimes drawn blank or garbled (see http://x.dsl.suomi.net/moz.png).

still occurs in the latest linux nightly, 20-03-2000.
Created bug #33298 specifically about the tree view. Pavlov, add dependency, if

appropriate.


Maybe someone can explain this:
Mozilla startup takes ~17sec. This more than twice the time Moz4.x needs to
bring-up it's window.
Any comments ?
Is there a bug for this ?
Target Milestone: M15 → M16
Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2
Target Milestone: M16 → M17
moving to m18
Target Milestone: M17 → M18
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
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. Should a seperate bug be filed on linux XPFE perf?
I have to disagree with the above poster with respect to HTML rendering. HTML
rendering is still unacceptable. True, it seems to be from 10 to 100
times faster than it was last september, but last september, it was verging
on a thousand times slower than Netscape 4 (which is in no way fast!). 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. eg., you change windows, and instead
of immediately clearing the newly drawn window and constructing it as one would
expect, it instead just sits there for a while apparently doing nothing at all,
as if no glacially slow window redraw is ever going to happen.

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? This bug seems very general.

I would think that this bug should be left to HTML rendering, and that's it.   
(1 bug per bugzilla report)

What't I've noticed with the Linux builds is that it appears that it tries to 
render the entire page first, and then display it to the screen.   (As opposed 
to the Win32 behavior I've noticed of drawing it do the screen as it's loaded 
and doing incremental reflows)
wdormann, it can't be "left" to HTML rendering, as nobody yet defined it as
such. Widgets are rendered as well. Without knowing the details, I guess, their
spped is closely related.

I suggest to file bugs for specific outstanding slow areas and implementation
proposals (e.g. "don't clear window twice") and make them dependant on this one.
Additionally, we can use this bug to track the remaining work (which is not
worth to file a bug about).
No longer blocks: 12761
Depends on: 43789
*** Bug 44049 has been marked as a duplicate of this bug. ***
I concur with Mr. 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.  Netscape 4.73,
on the other hand, takes less than a second.

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. which refresh every 2 minutes.  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.  The build I'm using (063008) is certainly
faster than Netscape 4.73 is under those circumstances though. (Netscape just
halts crash-like for about 30 seconds while it renders all the tables)
I believe the issue with multiple windows would be rememdied concurrently with a
solution to bug 40848 (added to "depends on").  Multithreading Mozilla is a big
effort, I imagine, and in my humble opinion, not one to be taken up on just yet
when stability is paramount.

Cheers!
Depends on: thread
For people having problems with multiple windows (and frames) see bug 42321 and
related bugs (GC needs more scalability).
Time to decide on nominating for nsbeta3, which will require a compelling reason
based on user-centered metrics ('slower than Windows' is not even close), or
targetting Future.
nominating for nsbeta3

Does "Windows is much too slow, and Linux is even several times slower
than Windows, making the product feel heavy and pretty much unusable for daily
work." sound better?

Please compare Mailnews on Windows and Linux, e.g. something as common as
replying to a msg or scrolling a folder > 1000 msgs.

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).
Keywords: nsbeta3
If you don't buy me, please see the cc list and votes on this bug.
nsbeta3+, addresses several of marketing's Top Perf Issues.
Whiteboard: [nsbeta3+]
Target Milestone: M21 → M18
adding myself to CC... go Linux!
nice catch by Tomi Leppikangas.. this avoids calling XSetFont every time we draw
text.
heres a new patch...  this one fixes a bug in the last one that happened due to
nsFont*::DrawString possibly not setting the current font, which UpdateGC
uses... so i've fixed this in this patch... but it will now be calling UpdateGC
in a for loop, so uh... if we don't find matches, we're gonna suck.
Nice. The patch really seems to speed things up on my system.
Here is some hard numbers. I made xul window with 100 transparent gifs
and run it trought xmon.

With nightly 2000080808:
230    CreateGC
205    ChangeGC
200    CopyGC
  6    SetClipRectangles
204    FreeGC
205    CopyArea

With pavlows nsImageGTK patch (coming soon?):
 41    CreateGC
205    ChangeGC
  1    CopyGC
 16    SetClipRectangles
  9    FreeGC
207    CopyArea

Thats huge speedup too.

There is still wery bad things in nsViewmanage2's "doublebuffering", that
creates too many GC:s. If you disable doublebuffering, things start
to fly.
My nsViewManager overhaul may have some impact here...
Here is values from full repaint of "mozilla about:blank" ,  there is
listed all calls to X-server.

With nightly 2000080808:
10    CreatePixmap       
10    FreePixmap       
56    CreateGC       
31    ChangeGC       
21    CopyGC       
17    SetClipRectangles       
56    FreeGC       
28    CopyArea       
 8    PolySegment       
 7    FillPoly       
24    PolyFillRectangle       
21    PolyText8       

With nsIMageGTK patch:
10    CreatePixmap       
10    FreePixmap       
35    CreateGC       
31    ChangeGC       
17    SetClipRectangles       
35    FreeGC       
28    CopyArea       
 8    PolySegment       
 7    FillPoly       
24    PolyFillRectangle       
21    PolyText8       

tomi: yer patch looks cool...  it might be good thought to just do a single
XChangeGC instead of all the individual calls.
Here is values from imagepatch + my gccache patch #2:

10    CreatePixmap
10    FreePixmap
18    CreateGC
31    ChangeGC
17    SetClipRectangles
18    FreeGC
28    CopyArea
 8    PolySegment
 7    FillPoly
24    PolyFillRectangle
21    PolyText8

Here is yet another speed improvment, this speeds up resizing panels
and frames quite much.

Why it does so? 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.

Index: gfx/src/gtk/nsRenderingContextGTK.cpp
===================================================================
RCS file: /cvsroot/mozilla/gfx/src/gtk/nsRenderingContextGTK.cpp,v
retrieving revision 1.124
diff -u -r1.124 nsRenderingContextGTK.cpp
--- gfx/src/gtk/nsRenderingContextGTK.cpp       2000/08/09 20:15:08     1.124
+++ gfx/src/gtk/nsRenderingContextGTK.cpp       2000/08/11 15:58:15
@@ -1655,7 +2078,7 @@
                          srcX, srcY,
                          drect.width, drect.height);
                      
-
+  XSync(GDK_DISPLAY(), False);
   return NS_OK;
 }
 

Ok, that XSync calls bit too oftern.. you could put
if(aCopyFlags & NS_COPYBITS_USE_SOURCE_CLIP_REGION)
before it, so it only gets called from nsViewManager2::Refresh. 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).

And you could remove XSync from gdksuperwin.c withs this on.
Adding myself to cc.

Adding myself to cc.

Adding myself to cc.
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'? =) keep em comin!
i'm more interested in closing this bug and (not) opening a bug saying windows
is slower than linux ;)
Yeah, but chances are that will be fixed in such a way that this one will 
need to be reopened ;-)
I say, let's not turn this into a leap-frog game.  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!
yes, i'm tired of this bug.  i think it has served enough of a purpose, and
should marked fixed... while its not entirely fixed, its good enough for now. 
If specific things suck, file new bugs on them.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
How many new things would you like?  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?

I think the main problem with this bug is that it was too broad.  Broad, generic
statements like "the product crashes," or "the performance really sucks" are NOT
terribly useful.  Granted, they might be TRUE, but even if that is the case, I'm
sure you will agree that it is far easier to point to the problem when it is
narrowed down to things like "it crashes in this routine, or in this situation,"
or "the performance of this routine is slower than it should be."  I have
noticed that the more specific bugs stand a better chance of being
scientifically probed and analyzed, and that is not surprising.  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.
You should file bugs on anything you think is enough of a problem, but the ones
you mentioned aren't really specific enough.  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.
My initial comments were directed at elladan's examples.  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.  Open a fresh, new bug instead.
Ironically, this "vague" bug has produced very significant results (thanks, 
btw!) -- so much so that I no longer feel embarrassed demoing Mozilla to my 
friends.
I agree with Matthew Miller's recent comment.  This bug HAS produced some very
positive results.  And what's more, the results are VERY much visible to the
average end-user.  This is all VERY good indeed.  However, I still believe this
bug started off much too broad and general.  That, my friends, is EXACTLY what
opens the door for questions like "what do you mean by slower than Windows?", or
"shall we open a bug saying Windows is slower than Linux when Linux surpasses
Windows?".

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.  Do we really want a situation like this?  (Peter, please
correct me if I'm wrong about any of this.  I don't mean to put words in your
mouth.)
"Also, not only does it open the door to things like the leap-frog sillyness we
encountered here"

And silliness it was indeed. A joke, nothing more. I hope those are still
allowed in Mozilla bug reports?
Opening New Window slowness: Bug 49141.
Oops.  I meant Peter Trudelle when I asked him to correct me. :-)  But I also
want to apologize to Peter Annema.  I did NOT mean to be a wet-blanket on jokes.
 I *LOVE* seeing jokes in bugs (example: bug 9940), and I really really hope to
continue seeing them.  I wasn't meaning to stomp on him.  I was simply trying to
illustrate how broad, general, or vague comparisons like "slower than Windows"
can lead to confusion or uncertainty about things, like what it takes to
consider the bug "fixed."  I believe this is what opened the door for Peter's
joke in the first place, and I thought his joke illustrated a good point. :-)  A
good bug should have very clear criteria by which to consider it "fixed."  This
bug did not really have any clear criteria for
 being considered fixed, which I think is what lead Pavlov to say in the end,
"I'm tired of this bug . . . while its not entirely fixed, its good enough for
now."  If we really knew what had to be done to consider the bug fixed, we
wouldn't have had this problem.
Marking verified in the Aug 25th build.
Status: RESOLVED → VERIFIED
No longer depends on: thread
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: