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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: harunaga, Assigned: roc)
References
()
Details
(Keywords: regression, testcase)
Attachments
(2 files)
(deleted),
patch
|
dbaron
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
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.
Updated•21 years ago
|
Flags: blocking1.6?
Reporter | ||
Comment 1•21 years ago
|
||
-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)
Reporter | ||
Comment 2•21 years ago
|
||
testcase2:
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=1943&action=view
only -moz-opacity:1 is visible on Mac.
related to Bug 212366.
Assignee | ||
Updated•21 years ago
|
Priority: -- → P2
Updated•21 years ago
|
Flags: blocking1.6? → blocking1.6-
Comment 3•21 years ago
|
||
*** Bug 230869 has been marked as a duplicate of this bug. ***
Comment 4•21 years ago
|
||
*** Bug 232070 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Summary: Mac builds don't render contents with -moz-opacity (except % value) → Mac builds don't render contents with -moz-opacity < 1.0
Comment 5•21 years ago
|
||
i've seen this before as well.
Comment 6•21 years ago
|
||
Do we have any traction at all here? Is this a double-buffering issue of some sort?
Assignee | ||
Comment 7•21 years ago
|
||
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.
Assignee | ||
Comment 8•21 years ago
|
||
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.
Assignee | ||
Comment 9•21 years ago
|
||
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 10•21 years ago
|
||
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+
Assignee | ||
Comment 11•21 years ago
|
||
> 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
Assignee | ||
Comment 12•21 years ago
|
||
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•21 years ago
|
||
I wish there was a way we could push blending off to the OS, rather than doing
it ourselves.
Comment 14•21 years ago
|
||
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•21 years ago
|
||
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?
Assignee | ||
Comment 16•21 years ago
|
||
> 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.
Assignee | ||
Comment 17•21 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 18•21 years ago
|
||
*** Bug 236499 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 19•21 years ago
|
||
*** Bug 238042 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 20•21 years ago
|
||
*** Bug 238754 has been marked as a duplicate of this bug. ***
Comment 21•21 years ago
|
||
*** Bug 243367 has been marked as a duplicate of this bug. ***
Comment 22•21 years ago
|
||
*** Bug 243352 has been marked as a duplicate of this bug. ***
Comment 23•20 years ago
|
||
if the fix is in, it doesn't work. see http://bugzilla.mozilla.org/show_bug.cgi?id=246287
Comment 24•20 years ago
|
||
damn it, sorry for the spam. checked this bug in 0.8--0.9 RC it's fixed. my fault. =(
Comment 25•20 years ago
|
||
*** Bug 246287 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 26•20 years ago
|
||
*** Bug 247183 has been marked as a duplicate of this bug. ***
Comment 27•20 years ago
|
||
"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+
Reporter | ||
Comment 28•20 years ago
|
||
crot0, that testcase works for me using Firefox-trunk 20050210 on Mac OS 10.3.8.
Comment 29•20 years ago
|
||
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+
Reporter | ||
Comment 30•20 years ago
|
||
crot0, that is another bug. Please search the bug or file it.
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•