193849 - Move 'opacity' handling down into GFX

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

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)

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

mine

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.)

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[Roland Mainz]

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

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 7

[Markus Hübner]

Will this also fix bug 195883 ?

Comment 8

[Markus Hübner]

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

Comment 9

[Roland Mainz]

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... :)

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 11

[Simon Fraser [no longer active]]

> > 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.

Comment 12

[Zibi Braniecki [:zbraniecki][:gandalf]]

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

Comment 13

[Olivier Cahagne]

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.

Comment 14

[Xanthor Sccas]

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.

Comment 15

[Colin S]

+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.

Comment 16

[Jonathan Stanley]

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.

Comment 17

[Colin S]

Testcase is broken, still available in Wayback Machine:

http://web.archive.org/web/20040103183701/http://alladyn.art.pl/gandalf/MozillaTests/dynl-c31.html

Comment 18

[Jonathan Stanley]

Attachment: Original test-case attached

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

Comment 19

[Eli Friedman]

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