228441 - Mac builds don't render contents with -moz-opacity < 1.0

Status: RESOLVED FIXED

(Core :: Web Painting, defect, P1)

Description

[HARUNAGA Hirotoshi]

Recent builds on Mac 2003120605/2003121305 sometimes don't render
contents with -moz-opacity.
See the URL or the testcase attachment 122096 [details] in bug 203910 on Mac.
Testcases in Bug 113327 don't cause this problem.
And 1.5/Mac works fine.
regression.

Comment 1

[HARUNAGA Hirotoshi]

-moz-opacity:75% is shown, but -moz-opacity:0.75 is not shown on Mac. 

2003102905/Mac can show the contents, although scrollbar doesn't work
as expected.
2003111503/Mac shows nothing.

Comment 2

[HARUNAGA Hirotoshi]

testcase2:
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=1943&action=view

only -moz-opacity:1 is visible on Mac.

related to Bug 212366.

Comment 3

[Stefan [:stefanh]]

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

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 5

[Mike Pinkerton (not reading bugmail)]

i've seen this before as well.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Do we have any traction at all here?  Is this a double-buffering issue of some sort?

Comment 7

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

I just haven't had time to get to this. It will require some debugging of Carbon
code which is going to take me a while.

Comment 8

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

Attachment: fix

This patch fixes the bug.

The problem was simply that in Carbon we don't do our own double-buffering
because Quartz does it for us. We need double-buffering turned on to do
blending properly, now, because blending needs to be able to read the "current
pixel values" during rendering.

The solution is to force on double-buffering when blending is required. To make
it work smoothly I had to reorganize nsViewManager::RenderViews a little bit so
that we compute the display list before we decide whether to do
doublebuffering.

Comment 9

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

Comment on attachment 141478 [details] [diff] [review]
fix

OK OK this is an easy one for a change, David :-)

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 141478 [details] [diff] [review]
fix


>+PRBool nsViewManager::BuildRenderingDisplayList(nsIView* aRootView,
>+  const nsRegion& aRegion, nsVoidArray* aDisplayList) {

Maybe put this brace on its own line?  Likewise for BuildDisplayList and
BuildEventTargetList?

If you're not worried about
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/base/src/nsObje
ctFrame.cpp&rev=1.439&mark=814-824#814
or even if you are, r+sr=dbaron.

Comment 11

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

> Maybe put this brace on its own line?

OK

Translucency and plugins won't work together on the same page. But they never
did, really.

Comment 12

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

Also, that AllowDoubleBuffering code doesn't really work. For example, a plugin
inside an IFRAME isn't currently disabling double buffering if the paint
originates outside the IFRAME.

Comment 13

[Simon Fraser [no longer active]]

I wish there was a way we could push blending off to the OS, rather than doing
it ourselves.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Wouldn't we need to switch all of Mac gfx to <insert the name of the new API
here> in order to do that, though?

Comment 15

[Simon Fraser [no longer active]]

Quatz (aka Core Graphics) does support opacity better than QuickDraw, yes.

But the issue here seems to be that we need to read the pixels in the
destination surface in order to do our own blending. We'd get better performance
if we could just draw in back-to-front layers directly to the window bits, using
an OS call to draw each layer into the destination with a given opacity. Or are
there situations in which that isn't possible?

Comment 16

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

> We'd get better performance if we could just draw in back-to-front layers
> directly to the window bits, using an OS call to draw each layer into the
> destination with a given opacity.

It's not that simple. Group opacity requires that we render an entire group of
elements into a temporary buffer and then composite that buffer in one operation.
http://ocallahan.org/mozilla/view-talk/img10.html and following. You can't just
call "SetOpacity(0.7);" and render as normal.

This should definitely be done by the system via a fancier graphics API. We can
extend nsIRenderingContext to do it, we don't need to rewrite the world. There
are a bunch of things that should be coordinated though (like fixing the
horribly broken offscreen graphics memory APIs, and evolving all platforms in
sync). It's just something no-one's had time to do yet.

Comment 17

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

Fix checked in.

Comment 18

[HARUNAGA Hirotoshi]

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

Comment 19

[HARUNAGA Hirotoshi]

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

Comment 20

[HARUNAGA Hirotoshi]

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

Comment 21

[Boris Zbarsky [:bzbarsky]]

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

Comment 22

[Boris Zbarsky [:bzbarsky]]

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

Comment 23

[Garrett Murray]

if the fix is in, it doesn't work. see http://bugzilla.mozilla.org/show_bug.cgi?id=246287

Comment 24

[Garrett Murray]

damn it, sorry for the spam. checked this bug in 0.8--0.9 RC it's fixed. my fault. =(

Comment 25

[Garrett Murray]

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

Comment 26

[HARUNAGA Hirotoshi]

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

Comment 27

[Hiro]

"opacity: 0.5;" doesn't work by the test case of bug281953. 
Test Case:
https://bugzilla.mozilla.org/attachment.cgi?id=174065

In the Windows version, it works. 
Screen shot of Firefox Windows version:
https://bugzilla.mozilla.org/attachment.cgi?id=174066

Mac OS X 10.3.8

trunk Camino 2005020921 (v0.8+)

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.8b) Gecko/20050209
Firefox/1.0+

Comment 28

[HARUNAGA Hirotoshi]

crot0, that testcase works for me using Firefox-trunk 20050210 on Mac OS 10.3.8.

Comment 29

[Hiro]

Attachment: screen sot of test case bug281953

It doesn't seem that opacity is reflected though a new profile was made again
and tried with latest 
nightly build. 

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050212
Firefox/1.0+

Comment 30

[HARUNAGA Hirotoshi]

crot0, that is another bug.  Please search the bug or file it.