If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Very slow painting of background 8-bit-alpha png

RESOLVED WORKSFORME

Status

()

Core
Graphics
RESOLVED WORKSFORME
14 years ago
6 years ago

People

(Reporter: bz, Assigned: tor)

Tracking

({perf})

Trunk
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: LINUX ONLY, URL)

Attachments

(3 attachments, 4 obsolete attachments)

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...
Created attachment 148078 [details]
Profile, in case someone wants to see it
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
(Assignee)

Comment 3

14 years ago
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.)
(Assignee)

Comment 5

14 years ago
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
Assignee: blizzard → tor
(Assignee)

Comment 8

14 years ago
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.

Comment 10

14 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

14 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

14 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

14 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.
Whiteboard: LINUX ONLY
(Assignee)

Comment 14

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.
Attachment #148165 - Attachment is obsolete: true
(Assignee)

Comment 15

14 years ago
Created attachment 148781 [details] [diff] [review]
flesh out all-RENDER nsImageGTK
Attachment #148762 - Attachment is obsolete: true
(Assignee)

Comment 16

14 years ago
Created attachment 148949 [details] [diff] [review]
add clipping to RENDER nsImageGTK
Attachment #148781 - Attachment is obsolete: true

Comment 17

14 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/
(Assignee)

Updated

14 years ago
Blocks: 134464
Blocks: 245899

Comment 19

13 years ago
The patch doesn't apply against current AVIARY.  Though that's not extremely
surprising.
(Assignee)

Comment 20

13 years ago
Created attachment 154811 [details] [diff] [review]
update to tip
Attachment #148949 - Attachment is obsolete: true

Comment 21

13 years ago
Created attachment 157808 [details]
Testcase with many layered pngs, was fast in older firebirds
Isn't that bug related to bug 64401? Both bugs reporting about the similar
problem IMO.

Comment 23

12 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

11 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.
WFM, Firefox trunk on Linux.
Component: GFX: Gtk → GFX: Thebes
Doesn't work for me, on the original URI (which has changed somewhat, but not too much). Trunk Linux, FC4.
QA Contact: ian → thebes
WFM with FF8 and a Nvidia card, on the original URL.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.