The testcase is djst's blog. djst, please don't change those images without giving me a chance to attach a testcase to this bug before you do, ok? ;) To reproduce (2004-05-02-06 nightly Seamonkey GTK1 build here), just try scrolling the page. It's slow as molasses... (p3 733 using a RIVA TNT2 video card with 16MB ram). The basic problem, as far as I can see, is that we have a background png with 8-bit alpha here. It's also huge: 2000x2000 pixels. I profiled scrolling, and of the 293133 total profiler hits, the breakdown was as follows: 252101 under nsCSSRendering::PaintBackground ~25000 under g_main_poll (us being idle) The rest various overhead (like actually scrolling). The 252101 hits under nsCSSRendering::PaintBackground break down as: 250705 nsRenderingContextImpl::DrawTile 841 nsCSSRendering::PaintBackgroundColor 202 nsPresContext::LoadImage 119 nsNativeThemeGTK::DrawWidgetBackground and some minor overhead Anyway, the upshot is that we end up with 250007 hits nsImageGTK::DrawCompositeTile, which splits up as: 212628 under XGetImage 27874 under nsImageGTK::DrawComposited32 8972 under gdk_draw_rgb_image Almost all the XGetImage time is spent in select(), of course. Maybe we should consider keeping 8-bit-alpha images locally in-process, not just on the X server if they're so slow to paint otherwise? If we want to keep the non-background ones only on the X server but keep backgrounds in-process, that can be done too -- libpr0n is sorta told whether an image is a background (in the loadflags), right? Or is this just an X configuration issue of some sort? I'm running XFree86 4.2.0, and the MIT-SHM extension seems to be there...
Note bug 242364 has similar problems with XGetImage (with a different callstack, and one where it's less obvious to me how to avoid hitting the server). The other thing worth exploring, of course, is whether we can possibly do some of this manipulation server-side...
We do keep 8-bit alpha images on the client side - what you're seeing is the readback of the target area so we can do the composite, which is our only option unless we want to start using XRender directly.
Oh, ok. Yeah, that's harder.... Is there a (cheap) way to detect XRender and use it if it's there and fall back on this code if it's not? That would let us tile completely server-side, right? (Which would be great for remote X performance on this page too, probably.)
We could start using XRender with the appropriate build config detection and the standard extension query mechanism. It's just that 8-bit alpha PNGs are rare enough on the web (probably due to Win32-IE not supporting than) that improving the performance of this hasn't been a high priority.
Ah, ok. Yeah, if we could fix this that'd rock. May even speed up some themes, if those use transparent pngs, since Render should be around on most modern systems. I just checked and the scrolling on this site is dog-slow in Opera too, btw (it does support 8-bit png).
-> over to tor
Created attachment 148165 [details] [diff] [review] render use test patch Attached is the first step towards using Xrender - just the untiled, unscaled case. It seems to work for most images, but when it goes wrong things get a bit strange (especially if you switch from PictOpOver to PictOpSrc). I'd appreciate it if people could give it a try on the following page: http://www.libpng.org/pub/png/pngs-img.html If when you scroll to the bottom you see a picture of a magnolia tree and an owl on the left, I'd like to know what X server and/or distribution you're running.
For reference Bug 90198 also reference djst's attempt to cause people's CPU's to ignite into flames.
tor: The patch works fine for me. That is, I don't see any differences in rendering pre- and post-patch - I didn't measure performance. I'm using XFree86 Version 4.4.0 from a Slackware 9.1 distribution (Xrender 0.8.4). I'm also using a 2.6.6 kernel, but I doubt that matters.
On my Redhat 9 box running on an ATI Radeon 7500, I get some bizzare rendering for the owl and magnolia pngs on tors testpage. The ice and firebrush pngs render okay. Screenshot here http://media.mumineen.org/tor.png I tested with a depend build of Firefox. Apparently clobber builds on Linux trunk are having some major regressions wrt bug 243210
Another testcase: http://www.grack.com/main/Home.html 8-bit PNG overlaid on top of an 8-bit PNG, both fixed-positioned. Neither of the images is huge, but it chugs when you scroll in Win32.
Comments windows is very slow to render in Windows too. I have AMD Athlon 64 3000+ and ATI Radeon 9600 XT and Mozilla nightly 2004051608 and it is scrolling very slowly.
14 years ago
Created attachment 148762 [details] [diff] [review] all-RENDER nsImageGTK.cpp A version of nsImageGTK.cpp that does all drawing with RENDER. This isn't how it would eventually go in the tree, where it would coexist with the current version and be selected at build and runtime based the existence of the extension. It's also not completely finished, but should be useful for testing purposes. The disappearing images seem to have been caused by setting the repeat attribute on the picture. I only enable that when tiling now, so only the occasional background should disappear.
Created attachment 148781 [details] [diff] [review] flesh out all-RENDER nsImageGTK
Created attachment 148949 [details] [diff] [review] add clipping to RENDER nsImageGTK
Be careful : I have this bug too with Firefox 0.8 under Windows XP. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Another excellent testcase: http://www.chevrel.org/fr/carnet/
14 years ago
The patch doesn't apply against current AVIARY. Though that's not extremely surprising.
Created attachment 154811 [details] [diff] [review] update to tip
Isn't that bug related to bug 64401? Both bugs reporting about the similar problem IMO.
(In reply to comment #22) > Isn't [this?] bug related to bug 64401? This bug is about 8-bit-alpha (PNG) backgrounds being slow to scroll on Linux specifically; the other bug is about pages with (large, maybe transparent, GIF or PNG) backgrounds being slow to scroll generally (and generally on Windows). There's some overlap, but they're not the same bug.
I played with oprofile on an optimized cairo build. I loaded djst's page, and kept scrolling for a while. Maybe these results could be useful. opreport -t1 --symbols Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 100000 samples % image name app name symbol name 63838 15.7916 Xorg Xorg (no symbols) 58906 14.5715 no-vmlinux no-vmlinux (no symbols) 50555 12.5058 nvidia_drv.so Xorg (no symbols) 25568 6.3247 libfb.so Xorg fbRasterizeEdges 20498 5.0706 libfb.so Xorg fbCopyAreammx 20193 4.9951 libfb.so Xorg fbSolidFillmmx 18587 4.5979 libfb.so Xorg fbCompositeSolidMask_nx8x8888mmx 9943 2.4596 oprofiled oprofiled (no symbols) 4727 1.1693 libc-2.5.so firefox-bin msort_with_tmp 4247 1.0506 libfb.so Xorg fbFetch At least we can see that not much is happening in Gecko. As a side note, I can see a different behavior between non-cairo 1.8 and cairo 1.9 scrolling in that case: with 1.8, the scrolling is quite fast, and the image stays in place. But in 1.9, the image "shakes" while scrolling, as if there is one repaint with the background image scrolled a bit, and then a repaint of the image at the original fixed location.
WFM, Firefox trunk on Linux.
Doesn't work for me, on the original URI (which has changed somewhat, but not too much). Trunk Linux, FC4.
WFM with FF8 and a Nvidia card, on the original URL.