I checked my results on http://alladyn.art.pl/gandalf/MozillaTests/dynl-c31.html with new machine. Athlon 1.8, Windows XP, GeFroce4, 512 DDR. Quite fast machine. But at this test, Mozilla still render Opacity changes with full redraw, while IE6 even on Athlon 700 do it smoothy. Also we're much slower than IE in Opacity drawing and we take much more processor power. Actual result: Mozilla render opacity animation slow and chopped Best result: Mozilla render opacity animation smoothly, fast, and without bothering processor (too much)

mine

In case anyone cares, I profiled this testcase once. The largest chunk of time (something like 60-70%) was spent in nsBlender ("blend24" or whatever the function is called). I somehow suspect that our blending algorithm doesn't scale well to many objects (nonlinear in the number of objects), and the 200 divs here give it grief.

The algorithm is linear in the sum of the sizes of the translucent objects. So its scaling properties are about optimal. It is slow, though. We can fix that. In fact, I think I'll morph this bug into the changes required to fix it. Essentially what I want to do is to move all the cross-platform code that manipulates offscreen pixmaps down into GFX. The places where we currently use offscreen pixmaps will turn into explicit GFX APIs that can be reimplemented with platform-specific optimizations where possible: DOUBLE BUFFERING: Add explicit BeginRendering()/EndRendering() APIs to nsIRenderingContext. It will be up to GFX to decide when double buffering is needed and to implement double buffering whenever it is needed. GROUP OPACITY: Add BeginFilteredGroup(nsFilter,PRBool aGroupIsOpaque)/EndFilteredGroup(nsFilter) APIs to nsIRenderingContext. For now nsFilter will just contain one opacity value. GFX will have to maintain a stack of rendering buffers to contain the state of nested groups. WINDOW ALPHA CALCULATION: No new APIs required. nsIRenderingContext::EndRendering() will compute the alpha values and update the window if necessary. I think the best approach is first to sink the existing view manager code into some shared GFX code, which every toolkit will use at first. I'll do that here. Then we can get to work. For Windows we can specifically optimize the blending of opaque groups by calling AlphaBlend() instead of doing it by hand. (In the testcase here, the blended DIVs are opaque.) For all x86 platforms we could improve the nsBlender code for all cases (including blending non-opaque groups) by using MMX. (I have looked at the MMX instruction set and it seems to be doable.)

fwiw, I just retested with that testcase and varying the number of divs, and opacity times are indeed linear. So just ignore me. ;)

Please do not forge that not all of our supported gfx modules support alpha channel, offscreen surfaces etc. (for example gfx/src/ps/ does not support any of these features). IMHO there should be a (non-static!!) method in gfx/ to query an initalised nsIDeviceContext whether the requested object instance supports one of the following features: - Alpha blending - Alpha mask (e.g. 1bit alpha channel) - Offscreen surfaces

No, I haven't forgotten this :-). > - Alpha blending > - Alpha mask (e.g. 1bit alpha channel) > - Offscreen surfaces Eventually offscreen surfaces are not going to be exposed outside of GFX so that's not going to be an issue. If your GFX implementation can't do group filters (e.g., group alpha blending), then it will just have to do the best it can. For group alpha blending that could mean just ignoring the alpha blending and painting opaquely instead, or it could mean dithering the alpha value into a mask used for painting.

Will this also fix bug 195883 ?

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

Robert O'Callahan wrote: > Eventually offscreen surfaces are not going to be exposed outside of GFX so > that's not going to be an issue. Having support for using offscreen surfaces outside gfx may be a nice-to-have thingie - it would would have lots of possible good uses... :)

> it would would have lots of possible good uses like what?

> > it would would have lots of possible good uses > like what? Creating 'snapshots' of the current page, for thumbnail generation? I know of several embedding customers who will want this in the long run.

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

fwiw, compiling with SSE flag seems to improve perf by 5% with both opacity tests (given the fact all the other tests performed a little worse). Tests with Firebird 20030901 on a PIII, details here: http://forums.mozillazine.org/viewtopic.php?t=22830 comment 2 was mentioning MMX could speed up things and, as far as I understand (not an asm specialist), MMX can be considered as a "subset" of SSE.

I think I see this perf problem with linux also. For exemple, on this testcase http://electroide.hostrocket.com/opacity.xhtml , where opacity is changed with an :hover.

+vote I recently designed a page that uses opacity heavily, and it is SLOW. This bug seems to have become stagnant, but I think that it would be a good idea to get it resolved, especially if one of the platforms that Mozilla (Firefox) rides on is that it renders things FAST. Mozilla's opacity rendering is certainly NOT FAST.

vote++; for me too. Again I figured I start making use of our CSS3 friend "opacity" since it became enabled as of Mozilla 1.7b. However, should a page start using many elements with opacity and in conjunction with PNGs (with alpha) things can very much slow to a crawl under FireFox 1.0PR (Mozilla/5.0 (Windows; U; Windows NT 5.2; rv:1.7.3) Gecko/20040913 Firefox/0.10). Under my nightly build of SVG enabled Mozilla 1.8a4 (Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8a4) Gecko/20040921), there is a good improvement from I guess the usage of GDI+ (as per Bug 207146 ... https://bugzilla.mozilla.org/show_bug.cgi?id=207146) but still a rather jittery experience.

Testcase is broken, still available in Wayback Machine: http://web.archive.org/web/20040103183701/http://alladyn.art.pl/gandalf/MozillaTests/dynl-c31.html

A "local" copy of the document retrieved via The Way Back Machine.

Opacity handling is now done within Cairo, and nsBlender is gone, so there doesn't seem to be much point to keeping this open.