BUILD: Current trunk Linux build STEPS TO REPRODUCE: 1) Download https://bugzilla.mozilla.org/attachment.cgi?id=281427 and save it to a text file locally. 2) Create an HTML document with a single <iframe width="100%" height="100%"> in it that includes the text file (this allows timing the load in the HTML document). 2) Open that HTML document in the browser. EXPECTED RESULTS: Fairly quick rendering and painting ACTUAL RESULTS: Initial rendering takes 7-8 seconds on trunk (as compared to under a second on the 1.8 branch). Repaints are very slow (hang the X server for a second or two every time you mouse into or out of the window). Profiling one of those repaints shows the time is about 50-50 split between native them background rendering (presumably of the scrollbars?) and text painting. The latter spends a lot of its time under XRenderCompositeText8/16 as called from GlyphBuffer::Flush, but there's also some _cairo_pattern_acquire_surface, _cairo_scaled_glyph_lookup, etc. Setting the HTML document's root to "overflow:hidden" reduces the pageload time by about 50%. Amusingly enough, the time under background painting shows a lot of time spent under gdk_x11_font_get_name, which various things call by calling gdk_gc_set_values.

Wrong link? I get a semi-NSFW picture.

For the record though, I don't have any experience with Xlib at all (Ive only been using GTK up to this point), so if the cause is there then I wouldn't have a clue what to do.

> Wrong link? I get a semi-NSFW picture. Right link. That's why you have to locally save it to a text file. It used to be text/plain in that bug when initially posted, if you look at the bug info, but that's been changed. > For the record though, I don't have any experience with Xlib at all Sure. I cced you because the gtk native theming is involved. I'll post the profile in case it tells you anything.

I get an initial freeze of about 3 seconds, but after that everything is fine for me. No freeze after moving mouse out of the window or lagging or anything. My build is a bit old(ish) though Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007091510 Minefield/3.0a8pre

It's when you move back in that it's slow... About a second here; presumably less on your faster hardware. Watching a CPU meter there is instructive, In any case, try the same on branch to see the difference.

That's what I meant sorry, moving the mouse back in shows no problems. And I doubt I have faster hardware, I have a 2.0GHz Pentium 4 with 512MB of RAM; nonetheless I'll look at branch.

362682 might fix/make this better

as filed, i don't believe this is really a blocker -- don't load binary documents as text. if you have certain unicode documents that are really slow due to font fallback, those should probably block.

I think this should block, because this does happen in the wild. For example, http://mxr.mozilla.org/seamonkey/search?string=CreateWindowEx See bug 396732 comment #2.

> don't load binary documents as text No one does this on purpose. It'll just happen more and more often as sites switch to the new Apache version which sends "text/plain; charset=UTF8", which we don't sniff for being binary. Renominating based on the fact that this will bite real users.

> 362682 might fix/make this better I tried applying that patch, but 'patch' claims that the cairo-ft-font.c hunks are already in while the others are not or something. I'll retest once that lands.

is this better with current trunk builds?

Minusing and marking as wanted-1.9. Per discussion with Vlad and Stuart. Improvements in the underlying platform will improve this as well. It would be great to get help from the linux distros on this. If someone wants to work on this, feel free to take it.

> is this better with current trunk builds? The initial load is about 25% faster than before the patch for bug 362682 (so still a lot slower than branch). Mousing in or out of the window is actually _slower_ now than it was before the patch for bug 362682. I get a CPU spike and pretty much unresponsive browser for over two seconds every time. Note that in between filing this bug and now I upgraded my pango from 1.6 to 1.12. That cut the time for initial load from 8 seconds to 4 seconds. It didn't affect the hang on mouse in/out, as far as I can tell.

Interestingly, if I mouse in/out really fast, the CPU usage is actually lower. I have no idea why: we cache textruns for 30 seconds or so, right? So it's not like they're being evicted.... Of further interest, I get that hang with mozilla.org builds, but not with my own (profiling enabled) build.

I am closing this bug as WORKSFORME since I am unable to reproduce this bug with Firefox 47.0.1 nor Nightly 50.0a1 on Ubuntu 16.04.1 64-bit. Boris please reopen this bug report if it still reproduces.