Closed
Bug 243146
Opened 20 years ago
Closed 13 years ago
Very slow painting of background 8-bit-alpha png
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bzbarsky, Assigned: tor)
References
()
Details
(Keywords: perf, Whiteboard: LINUX ONLY)
Attachments
(3 files, 4 obsolete files)
153.09 KB,
application/gzip
|
Details | |
81.88 KB,
patch
|
Details | Diff | Splinter Review | |
157.04 KB,
text/html
|
Details |
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...
Reporter | ||
Comment 1•20 years ago
|
||
Reporter | ||
Comment 2•20 years ago
|
||
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...
Keywords: perf
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.
Reporter | ||
Comment 4•20 years ago
|
||
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.
Reporter | ||
Comment 6•20 years ago
|
||
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).
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.
Comment 9•20 years ago
|
||
For reference Bug 90198 also reference djst's attempt to cause people's CPU's to ignite into flames.
Comment 10•20 years ago
|
||
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.
Comment 11•20 years ago
|
||
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
Comment 12•20 years ago
|
||
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.
Comment 13•20 years ago
|
||
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.
Reporter | ||
Updated•20 years ago
|
Whiteboard: LINUX ONLY
Assignee | ||
Comment 14•20 years ago
|
||
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.
Attachment #148165 -
Attachment is obsolete: true
Assignee | ||
Comment 15•20 years ago
|
||
Attachment #148762 -
Attachment is obsolete: true
Assignee | ||
Comment 16•20 years ago
|
||
Attachment #148781 -
Attachment is obsolete: true
Comment 17•20 years ago
|
||
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/
Comment 19•20 years ago
|
||
The patch doesn't apply against current AVIARY. Though that's not extremely surprising.
Assignee | ||
Comment 20•20 years ago
|
||
Attachment #148949 -
Attachment is obsolete: true
Comment 21•20 years ago
|
||
Comment 22•19 years ago
|
||
Isn't that bug related to bug 64401? Both bugs reporting about the similar problem IMO.
Comment 23•19 years ago
|
||
(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.
Comment 24•17 years ago
|
||
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.
Reporter | ||
Comment 26•17 years ago
|
||
Doesn't work for me, on the original URI (which has changed somewhat, but not too much). Trunk Linux, FC4.
Updated•15 years ago
|
QA Contact: ian → thebes
Comment 27•13 years ago
|
||
WFM with FF8 and a Nvidia card, on the original URL.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•