Closed Bug 228441 Opened 21 years ago Closed 21 years ago

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

Categories

(Core :: Web Painting, defect, P1)

PowerPC
macOS
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: harunaga, Assigned: roc)

References

()

Details

(Keywords: regression, testcase)

Attachments

(2 files)

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.
Flags: blocking1.6?
-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.
Summary: Mac builds don't render contents with -moz-opacity (sometimes) → Mac builds don't render contents with -moz-opacity (except % value)
testcase2: http://bugzilla.mozilla.gr.jp/attachment.cgi?id=1943&action=view only -moz-opacity:1 is visible on Mac. related to Bug 212366.
Flags: blocking1.6? → blocking1.6-
Keywords: testcase
*** Bug 230869 has been marked as a duplicate of this bug. ***
*** Bug 232070 has been marked as a duplicate of this bug. ***
Summary: Mac builds don't render contents with -moz-opacity (except % value) → Mac builds don't render contents with -moz-opacity < 1.0
Blocks: 93156
i've seen this before as well.
Do we have any traction at all here? Is this a double-buffering issue of some sort?
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.
Attached patch fix (deleted) — Splinter Review
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 on attachment 141478 [details] [diff] [review] fix OK OK this is an easy one for a change, David :-)
Attachment #141478 - Flags: superreview?(dbaron)
Attachment #141478 - Flags: review?(dbaron)
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.
Attachment #141478 - Flags: superreview?(dbaron)
Attachment #141478 - Flags: superreview+
Attachment #141478 - Flags: review?(dbaron)
Attachment #141478 - Flags: review+
> 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.
Priority: P2 → P1
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.
I wish there was a way we could push blending off to the OS, rather than doing it ourselves.
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?
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?
> 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.
Fix checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 236499 has been marked as a duplicate of this bug. ***
*** Bug 238042 has been marked as a duplicate of this bug. ***
*** Bug 238754 has been marked as a duplicate of this bug. ***
*** Bug 243367 has been marked as a duplicate of this bug. ***
*** Bug 243352 has been marked as a duplicate of this bug. ***
if the fix is in, it doesn't work. see http://bugzilla.mozilla.org/show_bug.cgi?id=246287
damn it, sorry for the spam. checked this bug in 0.8--0.9 RC it's fixed. my fault. =(
*** Bug 246287 has been marked as a duplicate of this bug. ***
*** Bug 247183 has been marked as a duplicate of this bug. ***
"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+
crot0, that testcase works for me using Firefox-trunk 20050210 on Mac OS 10.3.8.
Attached image screen sot of test case bug281953 (deleted) —
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+
crot0, that is another bug. Please search the bug or file it.
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: