26502 - Linux rendering performance is slower than windows.

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Stuart Parmenter]

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)

Comment 1

[chris hofmann]

add perf keyword to get on waterson's radar

Comment 2

[Roland Mainz]

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 ?

Comment 3

[leger]

Putting on PDT+ radar for beta1.

Comment 4

[Stuart Parmenter]

the client does the flush, but it is in the xlib code, which we can't change and
have no control over it.

Comment 5

[Stuart Parmenter]

Removing PDT+ and beta1.  I find performance acceptable for a beta.

Comment 6

[Jesse Ruderman]

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.

Comment 7

[Stuart Parmenter]

sure there is.  linux should be faster. :-)

Comment 8

[Jesse Ruderman]

Time to bring out the flame guns :)

Comment 9

[Ramiro Estrugo]

Windows is always going to be faster, kids.

Comment 10

[Stuart Parmenter]

fuck off ramiro ;)

Comment 11

[moshev]

This might be related to bug #20242, please see for example the following URL:
http://www.linux-mandrake.com/lothar/news.html

Comment 12

[R.K.Aa.]

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

Comment 13

[elladan]

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

Comment 14

[moshev]

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

Comment 15

[Brad Behm]

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.

Comment 16

[janne hayrynen]

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.

Comment 17

[Ben Bucksch (:BenB)]

Created bug #33298 specifically about the tree view. Pavlov, add dependency, if

appropriate.

Comment 18

[Roland Mainz]

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 ?

Comment 19

[Peter Trudelle]

Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2

Comment 20

[Peter Trudelle]

moving to m18

Comment 21

[Peter Trudelle]

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

Comment 22

[Jeremy M. Dolan]

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?

Comment 23

[elladan]

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.

Comment 24

[WD]

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)

Comment 25

[Ben Bucksch (:BenB)]

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

Comment 26

[David Krause]

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

Comment 27

[Jason Spence]

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)

Comment 28

[Brian Hunt]

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!

Comment 29

[Marko Macek]

For people having problems with multiple windows (and frames) see bug 42321 and
related bugs (GC needs more scalability).

Comment 30

[Peter Trudelle]

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.

Comment 31

[Ben Bucksch (:BenB)]

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

Comment 32

[Ben Bucksch (:BenB)]

If you don't buy me, please see the cc list and votes on this bug.

Comment 33

[Peter Trudelle]

nsbeta3+, addresses several of marketing's Top Perf Issues.

Comment 34

[Alec Flett]

adding myself to CC... go Linux!

Comment 35

[Stuart Parmenter]

Attachment: patch to avoid an XSetFont for each text draw we do

Comment 36

[Stuart Parmenter]

nice catch by Tomi Leppikangas.. this avoids calling XSetFont every time we draw
text.

Comment 37

[Stuart Parmenter]

Attachment: new patch.. ignore the previous one

Comment 38

[Stuart Parmenter]

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.

Comment 39

[Matthew Miller]

Nice. The patch really seems to speed things up on my system.

Comment 40

[Tomi Leppikangas]

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.

Comment 41

[Robert O'Callahan (:roc) (email my personal email if necessary)]

My nsViewManager overhaul may have some impact here...

Comment 42

[Tomi Leppikangas]

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       

Comment 43

[Stuart Parmenter]

Attachment: patch to nsImageGTK to reduce the number of creategc/freegc calls

Comment 44

[Stuart Parmenter]

Attachment: more fun image patch.. is resizing pixmaps legal? :-)

Comment 45

[Tomi Leppikangas]

Attachment: patch for nsGCCache to reuse gcs

Comment 46

[Stuart Parmenter]

tomi: yer patch looks cool...  it might be good thought to just do a single
XChangeGC instead of all the individual calls.

Comment 47

[Tomi Leppikangas]

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

Comment 48

[Tomi Leppikangas]

Attachment: patch #2 for GCCache, uses XChangeGC

Comment 49

[Tomi Leppikangas]

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;
 }
 

Comment 50

[Tomi Leppikangas]

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.

Comment 51

[Jason Eager]

Adding myself to cc.

Comment 52

[kfir shay]

Adding myself to cc.

Comment 53

[Daniel Roberts]

Adding myself to cc.

Comment 54

[Jeremy M. Dolan]

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!

Comment 55

[Stuart Parmenter]

i'm more interested in closing this bug and (not) opening a bug saying windows
is slower than linux ;)

Comment 56

[Peter "jag" Annema]

Yeah, but chances are that will be fixed in such a way that this one will 
need to be reopened ;-)

Comment 57

[Stuart Parmenter]

Attachment: imot's gc cache patch cleanedup a lil

Comment 58

[Daniel Roberts]

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!

Comment 59

[Stuart Parmenter]

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.

Comment 60

[elladan]

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?

Comment 61

[Daniel Roberts]

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.

Comment 62

[Peter Trudelle]

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.

Comment 63

[Peter Trudelle]

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.

Comment 64

[Matthew Miller]

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.

Comment 65

[Daniel Roberts]

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

Comment 66

[Peter "jag" Annema]

"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?

Comment 67

[Ben Bucksch (:BenB)]

Opening New Window slowness: Bug 49141.

Comment 68

[Daniel Roberts]

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.

Comment 69

[Tomi Leppikangas]

Attachment: check if all other but clipregion matches in GCcache

Comment 70

[Chris Petersen]

Marking verified in the Aug 25th build.

Comment 71

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/75e0f4870275
[fenix] Closes https://github.com/mozilla-mobile/fenix/issues/26502: add isLocal parameter for history openItem telemetry event
https://hg.mozilla.org/releases/mozilla-beta/rev/6e4f54bc63b1
[fenix] For https://github.com/mozilla-mobile/fenix/issues/26502: Add time group and private extras in history telemetry