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)

Product:
Core
Component:
Web Painting
Platform:
PowerPC
macOS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: harunaga, Assigned: roc)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(2 files)

fix
16.05 KB, patch
dbaron
: review+
dbaron
: superreview+
Details | Diff | Splinter Review
screen sot of test case bug281953
5.61 KB, image/png
Details 
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
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 — — 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.
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

Creator:
Created:
Updated:
Size: