113232 - support transparent non-rectangular chrome windows

Status: RESOLVED FIXED

(Core :: XUL, defect, P1)

Description

[rvj]

will the <window/> element  support background-color:transparent allowing the 
desktop to be revealed?

It a couple of years since I originally raised this in the newsgroups and 
altough there seems enthusiasm for this, Im not sure if it is possible to 
implement.


The idea is that if a window background-color is transparent and background is 
set to a gif with transparent regions, then the desktop will be visible through 
the transparent regions  e.g. an artists palette

Or is there another solution that would allow the design of irregular (non-
rectangular) windows.????

Comment 1

[Boris Zbarsky [:bzbarsky]]

If we do this we should also do it for <iframe> and <menupopup>

Comment 2

[Chris Brien]

Yipes. This would require (in Windows 2000&XP) making the entire window
WS_EX_LAYERED, having Mozilla manage which areas of itself are transparent, and
changing the rendering code to render to a buffer instead of a window, which
Windows will then composite. This would only work in 2000&XP, although I'm sure
Mac OSX is capable of something similar.

Another nice feature of the WS_EX_LAYERED style is that irregular windows are
easy, so theme makers will be happy.

As a fall-back, for systems that don't support real transparency, the Desktop
image could be rendered behind the translucent content instead.

Comment 3

[David Hyatt]

--> default owner

Comment 4

[Joe Hewitt (gone)]

I'm researching ways to implement this on win32.

For the irregular window shapes, we need to calculate a polygon which defines
the outer edge of the window, and then call SetWindowRgn on the native window. 
Windows then takes care of clipping our pixels and keeping out mouse events on
the transparent regions.  

Comment 5

[Todd Cohn]

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

Comment 6

[Samir Gehani]

Nav triage team: nsbeta1+/adt2

Comment 7

[Jan Varga [:janv]]

-> me

Comment 8

[Jan Varga [:janv]]

targetting

Comment 9

[Alex Hosking]

doesnt this require using .png files for themes?
And i think this will make Mozilla cool

Comment 10

[Jan Varga [:janv]]

We're targetting on rounded corners for now.

Comment 11

[Jan Varga [:janv]]

Attachment: patch v0.1

initial patch

Comment 12

[Jan Varga [:janv]]

Attachment: testcase

testcase

Comment 13

[Jan Varga [:janv]]

Attachment: new patch

this one implements support for non-cotiguous regions too

Comment 14

[Jan Varga [:janv]]

Attachment: new testcase

Comment 15

[Jan Varga [:janv]]

Joe, could you r/sr ?

Comment 16

[Jan Varga [:janv]]

Attachment: better patch

Comment 17

[Jan Varga [:janv]]

cc'ing bryner for a review

Comment 18

[Brian Ryner (not reading)]

Comment on attachment 109166 [details] [diff] [review]
better patch

I really don't like the dependency of widget on layout (and the style system)
that this patch creates.  It seems like it would be better to define
nsWindowRegion in gfx or widget.

It would be nice to avoid the copy of the points in the gtk widget code, but it
looks like gtk uses 16-bit types for the coordinates.

Comment 19

[Jan Varga [:janv]]

Attachment: fix

nsWindowRegion moved to gfx/

Comment 20

[Jan Varga [:janv]]

Daniel, could you take a look at the patch ?
I fixed the gotos (not sure why I used them before)

Comment 21

[Brian Ryner (not reading)]

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

r=bryner on the gfx, xpfe, and widget changes, with one comment:  please make
sure to use the MPL license with the correct copyright year on the new files.

Comment 22

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

Why do you need a new CSS property? Can't we just implement the existing CSS
properties better? We could make 'background:transparent' and
'-moz-border-radius' on <window> (and popups) actually work. That could actually
be more convenient and more powerful than what you currently have.

Comment 23

[Jan Varga [:janv]]

notice, that this patch implements irregular shapes, not just rounded corners

Comment 24

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

Still, with a transparent popup you can put whatever shape you like inside the
popup. Your testcases are basically just images; it'd be much easier for authors
to simply use a transparent image than to generate complicated regions.

Here's what Jan and I agreed: we won't introduce any new CSS properties. We will
instead make 'background-color:transparent' on XUL <window>s Do The Right Thing.

Thus, I propose adding three nsIWidget APIs:
-- nsIWidget::SetWindowTransparency(PRBool aTransparent); makes a top-level
window support transparency (we call this from layout when we detect
background-color:transparent on a top-level XUL window)
-- PRBool nsIWidget::GetWindowTransparency()
-- nsIWidget::UpdateTransparentWindowAlpha(nsRect aUpdateArea, PRUint8*
aAlphaValues); sets the alpha values for the window's pixels (the parameter is a
w x h array of 8-bit alpha values) (this gets called by the view manager for a
transparent widget before copying the off-screen buffer to the window's
rendering context)

I have promised to modify the view manager so that when the window is
transparent, the view manager will compute the alpha values for every painted
pixel and send them to the widget.

To implement this on Windows ME/W2K/WinXP, nsIWidget::SetWindowTransparency will
call SetWindowLong to put the window into LAYERED mode. Invalidation and
painting for these windows will have to be modified because layered windows
don't invalidate and repaint normally. When Gecko calls nsIWidget::Invalidate,
the Windows widget code will issue an internal paint event. When the event is
received we set up a 32-bit bitmap, create a compatible DC and pass that DC into
the view manager as the DC to paint into. We capture the alpha values sent by
the view manager, and then when the view manager has finished painting we copy
the alpha values into the alpha channel part of the bitmap. Then we call
UpdateLayeredWindow, passing in the bitmap.

I think implementing this on GTK should be somewhat simpler. We just respond to
nsIWidget::UpdateTransparentWindowAlpha by updating the mask bitmap for the
window. (I guess we'll have to keep a cached mask bitmap around.)

Comment 25

[Jan Varga [:janv]]

Attachment: X11 Nonrectangular Window Shape Extension

Comment 26

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

Attachment: checkpoint

So here's where I'm at with general support for "background-color:transparent"
on windows. It doesn't work yet because I haven't tested it, but it does build
:-). This should show you what I'm trying to do. I'll try to get it working
tomorrow.

The widget code is only for GTK, Win32 support would have to be added
separately (and I can't do that since I don't have Windows around).

Comment 27

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

Attachment: better patch

This moves the setting of the transparent window flag from PaintBackground to
SyncFrameViewProperties. It's going to be important to get this flag set
outside the paint event. It's also lower overhead.

Comment 28

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

By the way, regarding -moz-window-region vs background-color:transparent...

Suppose the author wants to tile a background pattern over a window and also
have a transparent region. Well, if the window has a fixed size, then with
background-color:transparent the author can make a background image of that size
by hand-tiling the desired background pattern and then making the right parts
transparent --- should be easy with the right image editing tools. With
-moz-window-region you can use CSS to tile the background pattern, but then you
have to figure out the -moz-window-region coordinates by hand.

On the other hand if the window doesn't have a fixed size then
-moz-window-region isn't really usable.

The real difference is that -moz-window-region can clip elements such as text or
form elements in arbitrary ways. Thus I think it would be great to retarget
Jan's patch to be an extension to the existing 'clip' property.

Comment 29

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

Comment on attachment 110007 [details] [diff] [review]
better patch

The GTK code needs to be worked on to make it handle window resizing properly.
Right now it'll probably crash. When the window is resized we should also
resize the mask bit array and fill the "new" areas of the window with 1s.

Comment 30

[Jan Varga [:janv]]

ok, let's reuse the CSS part of my patch in future implementation of |clip:
polygon(x1,y1, x2,y2, ...)|

Comment 31

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

Attachment: patch v3

I'm going away until Jan 13 so here's where I'm at. The patch includes a lot of
#ifdef DEBUG_roc that you may find useful, if not just remove it.

I'll attach my testcase in another attachment. With this testcase, I have the
following problems remaining:
-- I'm not setting the GTK mask on the correct GtkWidget, I think, because the
window becomes sort-of-transparent but doesn't really work properly (maybe this
is because the border decorations are still there?) Anyway, I think this is a
GTK API problem because the correct alpha values ARE being sent down by the
view manager and the generated mask bits look right.
-- After some number of invalidates, we crash or hang. I think something in
this patch is corrupting memory :-(. Sorry, I was not able to track it down.
(Maybe we need to release the rendering contexts in ~BlendingBuffers() before
we destroy their surfaces?)
-- I haven't had a chance to test ComputeAlphas24 or ComputeAlphas32.
-- Need to fix up the mask array when we resize the GTK window. This doesn't do
that and usually just crashes when you resize.

For Windows, one thing that might be fairly easy to do is to build a similar
bit mask array as for GTK and then turn that into an HRGN and use SetWindowRgn.
Turn the bit mask into an HRGN by trying to a set of rectangles that combined
give you the bit mask. Of course the cool thing to do would be to use
UpdateLayeredWindow, which would let you use all 8 bits of alpha sent down by
the view manager, but that's a heck of a lot of work I think.

Good luck!

Comment 32

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

Attachment: XUL testcase

run dist/bin/mozilla -chrome <thisfile.xul>

Comment 33

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

Attachment: screenshot

I've made considerable progress. Here's a screenshot. I'll attach the testcase
that generated the screenshot in a moment.

Comment 34

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

Attachment: XUL testcase

UL testcase attached. Note "hidechrome", which I have revived support for, and
the "background:transparent".

Comment 35

[Jan Varga [:janv]]

Awesome!
I can try your patch as soon as I land other stuff from my tree.

Comment 36

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

WOAH! Animated GIFs just worked, first time I tried them. You have to see this
to believe it.

Comment 37

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

Attachment: animated octopus for the testcase

Comment 38

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

Attachment: updated testcase to test animation and complex regions

Comment 39

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

Attachment: screenshot of the animated testcase

Trust me, the octopus is animated on the desktop just like it is when you
display the GIF in your browser window!

Comment 40

[Jan Varga [:janv]]

Robert, you rock!
This will be killer feature of XUL

Comment 41

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

I'll attach my patch in a moment. It fixes all the issues I was stuck with
before. It's in pretty good shape actually, seems quite stable. It's not perfect
though; it doesn't really work when the XUL contains native child widgets (e.g.,
scrolling content). You probably don't need that right away, although it would
be super-cool to render Web pages directly onto the desktop. (But we are close
to being able to do that.)

Comment 42

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

Attachment: patch

Promised patch. This only does GTK of course. Someone else will have to do the
Windows and Mac parts.

BTW I used valgrind to find the memory corruption I was getting earlier. Worked
great.

Comment 43

[Jan Varga [:janv]]

Robert, what about landing what we have now and add implementation for other
platforms later ?
Mozilla 1.3 freeze is so close and I'm not sure if I will be able to add well
tested windows implementaton before the freeze.

Comment 44

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

if we can get it reviewed, sure.

Comment 45

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

roc, we should change your nick to rock+moz because, really, really, really,
you ***ROCK*** !!! This is awesome.

Comment 46

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

Attachment: Revised patch: layout changes

I've updated the patch with better comments (and also some changes to
nsContainerFrame that I forgot to include last time) and split it into three
parts: layout (to be reviewed by kin), views (to be reviewed by kmcclusk) and
widget+xpfe+gfx (to be reviewed by bryner).

Comment 47

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

Attachment: view changes

Comment 48

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

Attachment: gfx, widget, and xpfe changes

Comment 49

[Alex Hosking]

If this bug is fixed will that make Mozilla skinable in the same way as Real Player?

Comment 50

[Kevin McCluskey (gone)]

Comment on attachment 111959 [details] [diff] [review]
view changes

r=[e-mail]

Comment 51

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

Attachment: revised fix for gfx+widget+xpfe

This version adds some extra checks to catch potential issues with, say,
someone trying to load transparent chrome into an embedded context. We should
not honour transparency in that case.

Comment 52

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

Attachment: revised view patch

The last view patch had some bad hunks that belonged to another patch. This one
doesn't.

Comment 53

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

Comment on attachment 112243 [details] [diff] [review]
revised view patch

carrying forward r=, resetting kin sr request

Comment 54

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

Attachment: improved layout patch

Here's a new layout patch. This gets rid of the XUL dependency.

Comment 55

[Brian Ryner (not reading)]

Comment on attachment 112241 [details] [diff] [review]
revised fix for gfx+widget+xpfe

I'm not all that familiar with the gfx stuff here, but I trust roc.  The widget
code looks good, except that it could use a comment about how ChangedMaskBits
and UpdateMaskBits work.  Have you tested Txul with this change?

Comment 56

[Stuart Parmenter]

I hate to do this this late in the game, but unless someone can prove to me why
this is actually a good idea and not just this weeks cool shiny object, I'm
going to pull out my module owner badge and block this from going in to the tree.

Comment 57

[Stuart Parmenter]

I should add that if this "cool new feature" in XUL didn't require the massive
amounts of new code that I wouldn't have as much of a problem with it, but as it
is, this would add a lot of extra code that can't be factored out if you don't
want to include XUL.

Comment 58

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

Jan wants it for some Netscape/AOL project, I assume. I thought other people
could use this too, for themes and XUL apps and mozdev hacks like the circular
pop-up menu for mouse gestures. (To get translucent popups working might require
a few more changes to layout, but not much.)

The only major code addition is in GFX. The view patch is almost entirely
refactoring that should be done anyway, and the layout patch is small.

We could shrink the GFX/GTK code in a few ways. One way would be to not support
changing the mask or resizing the window. Another option would be to leave the
GFX hooks as they are, put the GTK-specific support inside #if 0 (or remove it
entirely), and let other platform owners decide whether they want the support.
Another option would be to put the GTK support inside #ifdef INCLUDE_XUL or the
equivalent thereof.

Comment 59

[Stuart Parmenter]

Perhaps make it a build flag so that people who don't want this support can 
disable it.. then it could work in addition to disabling XUL.  If it is going 
to be done, I don't think you can really remove the resizing or mask changing...

If you add up the different platforms code to support this, we're looking at a 
lot of new code being added to an area that isn't very well owned.  Are you 
going to own this code and fix all the bugs in it?

Is there someone signed up to do the work on Windows and on Mac?

Comment 60

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

I'm happy to own the GTK code for this. I already own views and nsBlender (the
latter perhaps not officially, but in practice).

I think Jan is planning to do the Windows work. I don't know if anyone is going
to  sign up for other platforms. But they don't, they just don't get the feature
on those platforms, and the only impact is 200 lines in nsBlender that they
won't be using.

I don't think we support top-level HTML windows, so there is no point in
enabling this if XUL is disabled. I think we may as well just test for XUL.

Comment 61

[Jan Varga [:janv]]

Yeah, I plan to add platform code for windows and maybe for mac too.

Comment 62

[Stuart Parmenter]

ok, so can we figure out what code isn't needed if xul is disabled?  bryner has 
builds working again without XUL so this is pretty important.  If we get that 
and Jan is going to own the windows code, then I'm ok with it going in.

Comment 63

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

Attachment: gfx+widget+xpfe patch, revised

OK, here are my INCLUDE_XULs to disable top-level window features if we're not
building with XUL.

Comment 64

[Brian Ryner (not reading)]

please use MOZ_XUL, not INCLUDE_XUL.  I'm changing all instances of INCLUDE_XUL
to MOZ_XUL in another patch.

Comment 65

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

Attachment: replaced INCLUDE_XUL with MOZ_XUL

Comment 66

[andreww]

Any idea when this may land?

Comment 67

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

Certainly not before 1.3final is branched. If you need this soon, consider
sending someone to pavlov and kin's offices to 'encourage' them to review the
patches.

Comment 68

[Stuart Parmenter]

Comment on attachment 113864 [details] [diff] [review]
replaced INCLUDE_XUL with MOZ_XUL

I don't understand why you removed this code..
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsWindow.cpp#872

Does the view manager do something similar now?  Even with the correct clipping
being set, this gave a very large performance increase on Unix when it was
added.	Why are we sending the bounding box at all if we're sending the region
in the nsPaintEvent?

Aside from that, the rest looks ok.

Comment 69

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

Sorry, that hunk is part of another patch and it slipped in by mistake. I'll
remove it and repost the patch.

FYI that hunk is part of the patch for bug 191474.

Comment 70

[Stuart Parmenter]

Comment on attachment 113864 [details] [diff] [review]
replaced INCLUDE_XUL with MOZ_XUL

ok, r=pavlov

Comment 71

[Jan Varga [:janv]]

There is a nice tutorial - Win32 Window Skinning
http://flipcode.com/articles/article_win32skins.shtml

Since the last patch differs from my last patch a lot, especially that we use
bitmaps instead of shapes (regions), we need to do it differently on windos.
::SetLayeredWindowAttributes() looks promising

Comment 72

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

There are two ways to go on Windows. You can either use SetWindowRgn or you can
use the Win2K/WinXP "layered window" APIs. The layered window APIs are probably
faster and they support translucency, but I suspect they'll be harder to
implement   since to get per-pixel alpha you have to use UpdateLayeredWindow,
which requires a change in the way we do painting for these windows. (You don't
do WM_PAINT/BeginPaint()/EndPaint() at all.) Also, layered windows won't work on
Win9x.

So I suggest that as a first step, you try using SetWindowRgn. If that doesn't
perform satisfactorily, or you want translucency to work on Win2K/WinXP, then
you can add code to use UpdateLayeredWindow when it's available.

To use SetWindowRgn you'll need algorithm which converts a bitmap into a region.
It's not that hard to do. There may be sample code for doing this somewhere on
the Internet already. You can borrow the GTK code to keep track of the complete
bitmap showing which pixels are transparent, and run your region conversion
algorithm whenever the bitmap changes.

Comment 73

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

Taking this to keep it on my radar

Comment 74

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

Comment on attachment 112243 [details] [diff] [review]
revised view patch

I didn't mean to give myself the review for this. sorry...

Comment 75

[Kevin McCluskey (gone)]

Comment on attachment 112243 [details] [diff] [review]
revised view patch

r=[e-mail]

Comment 76

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 112243 [details] [diff] [review]
revised view patch

>Index: view/src/nsViewManager.cpp
>+  it's an alternative double-buffer buffer that starts of white instead of black, and

"starts off".

>+  PRBool transparentWindow = PR_FALSE;
>+  if (widget) {
>+    widget->GetWindowTransparency(transparentWindow);
>+    if (transparentWindow) {
>+      // for a translucent window, we'll pretend the whole area is
>+      // translucent.
>+      mTranslucentArea = aRect;

Hmm... could we decide whether it's transparency or translucency and be
consistent (just to reduce confusion)?

It looks like there may be more drawing surface memory churn since we no longer
use global drawing surfaces and instead create them every time RenderViews is
called....  Is that going to have any performance impact?  Or do rendering
contexts do decent caching of drawing surfaces?

>+void nsViewManager::RenderDisplayListElement(DisplayListElement2* element,
>+  nsIRenderingContext &aRC, BlendingBuffers* aBuffers)

This is really oddly indented... Just make it three lines and indent all params
equally?

>+BlendingBuffers::BlendingBuffers(nsIRenderingContext* aRC) {
>+  mCleanupContext = aRC;

Would a more descriptive name than "aRC" be in order for that argument?  Like
"aCleanupContext" or something?

>   // create a blender, if none exists already.
>   if (nsnull == mBlender) {
>     rv = nsComponentManager::CreateInstance(kBlenderCID, nsnull, NS_GET_IID(nsIBlender), (void **)&mBlender);

While you're here, 

  rv = CallCreateInstance(kBlenderCID, &mBlender);

For that matter, make mBlender an nsCOMPtr and

  mBlender = do_CreateInstance(kBlenderCID, &rv);

sr=bzbarsky with the nits picked and the question about memory churn addressed.

Comment 77

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 112245 [details] [diff] [review]
improved layout patch

>Index: layout/html/base/src/nsContainerFrame.cpp
>     if (nsnull == rootParent) {
>       viewHasTransparentContent = PR_FALSE;

if (!rootParent) ?

>+  // XXX we should also set widget transparency for XUL popups that ask for it

Wouldn't that just work if you skipped the "toplevel document" check and set
widget transparency for any widget whose view has no parent?

In any case, could you add a comment right before the

+      if (bg->mBackgroundFlags & NS_STYLE_BG_COLOR_TRANSPARENT) {

line saying that we need to set window transparency on toplevel windows with
transparent backgrounds?

>+  return canvasFrame != nsnull
>+      ? FindCanvasBackground(aPresContext, canvasFrame, aBackground)

return canvasFrame ? ... : ...;

should work fine, no?

>     if (nsnull == rootParent) {
>-      // Ensure that we always paint a color for the root (in case there's

if (!rootParent)

r+sr=bzbarsky with the nits picked.

Comment 78

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 113864 [details] [diff] [review]
replaced INCLUDE_XUL with MOZ_XUL

>Index: gfx/src/nsBlender.cpp

>+  NS_ASSERTION(PR_FALSE, "GetAlphas not implemented because XUL support not built");

NS_ERROR, please.

>+/**
>+ * Let A be the unknown source pixel's alpha value and let C be its (unknown) color.
>+ * Let S be the value painted onto black and T be the value painted onto white.
>+ * Then S = C*(A/255) and T = 255*(1 - A/255) + C*(A/255).
>+ * Therefore A = 255 - (T - S)
>+ * This is true no matter what color component we look at.
>+ */
>+static void ComputeAlphas32(PRInt32 aNumLines, PRInt32 aNumBytes,
>+                            PRUint8 *aS1Image, PRUint8 *aS2Image,
>+                            PRInt32 aSLSpan, PRUint8 *aAlphas)

Could we make the args match the comment a bit better?	In particular, is
aS1Image or aS2Image painted on white?

>+    PRUint8 *s1 = aS1Image + 1;
>+    PRUint8 *s2 = aS2Image + 1;

Hmm... Why the + 1?  Because we're looking at component #1 (as opposed to
component #0)?
If so, please move that comment up here....

>+static void ComputeAlphas24(PRInt32 aNumLines, PRInt32 aNumBytes,
>+                            PRUint8 *aS1Image, PRUint8 *aS2Image,
>+                            PRInt32 aSLSpan, PRUint8 *aAlphas)

This is identical to ComputeAlphas32 except for doing +=3 instead of +=4. 
Should we just have one function that takes the "3" or "4" as an argument?

The comments above apply here too, of course.

>+      PRUint32 pix1 = GREEN16(*s1) >> (8 - BLEND_GREEN_BITS);
>+      PRUint32 pix2 = GREEN16(*s2) >> (8 - BLEND_GREEN_BITS);

Hmm... Could you comment those two lines a little bit?	Whence comes the magic
number "8"?  Why are we doing that bitshift?

All of this is using aNumBytes to mean aBytesPerLine; should it be called that?

>+  nsIDrawingSurface* srcSurface = (nsIDrawingSurface *)aBlack;
>+  nsIDrawingSurface* secondSrcSurface = (nsIDrawingSurface *)aWhite;

This I do not like one bit... if this is legal, why are we bothering with
nsDrawingSurface at al instead of just using nsIDrawingSurface?

Also, why are we losing the descriptive black/white names and using srcSurface
and secondSrcSurface?

>+  rangeCheck(srcSurface, r.x, r.y, r.width, r.height);
>+  rangeCheck(secondSrcSurface, r.x, r.y, r.width, r.height);
>+
>+  result = srcSurface->Lock(aRect.x, aRect.y, aRect.width, aRect.height,
>+                            (void**)&srcBytes, &srcRowBytes, &srcSpan, 
NS_LOCK_SURFACE_READ_ONLY);

What's the point of doing the rangeCheck if we're just going to use aRect here
and below?

>+          ComputeAlphas(srcBytes, srcRowBytes, secondSrcBytes, srcSpan,
>+                        aRect.height, *aAlphas, aRect.width*aRect.height, depth);

Hmm... Could we make the argument orders for ComputeAlphas and ComputeAlphasN
(for various N) match as much as possible?

>Index: widget/public/nsIWidget.h

>+     * Set the transparency of the top-level window that contains this
>+     * widget. This can fail if the platform doesn't support
>+     * transparency.

So if I call this on an <iframe>s widget, the transparency of the browser
window that contains the <iframe> will be set?	If not, could we adjust this
comment accordingly?

>Index: widget/src/gtk/nsWindow.cpp

>+  NS_RELEASE(event.renderingContext);

File a bug to make nsPaintEvent have an nsCOMPtr member there, maybe?

>   if (!mUpdateArea->IsEmpty()) {
>-
>-    PRUint32 numRects;
>-    mUpdateArea->GetNumRects(&numRects);

This looks like sneak-over from your GTK over-painting patch....  Which parts
of this diff are actually relevant to this bug?

I'm not reading the guts of the bit-twiddling code for now, pending getting
that part cleared up....

>Index: widget/src/gtk/nsWindow.h

>-  PRBool	      mIMECallComposeStart;
>-  PRBool	      mIMECallComposeEnd;
>-  PRBool	      mIMEIsBeingActivate;
>+  PRPackedBool        mIMEEnable;
>+  PRPackedBool	      mIMECallComposeStart;
>+  PRPackedBool	      mIMECallComposeEnd;
>+  PRPackedBool	      mIMEIsBeingActivate;

Tabs?  Please fix?

Comment 79

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

> Hmm... could we decide whether it's transparency or translucency and be
> consistent (just to reduce confusion)?

OK, I'll change all the new names to translucency since that's what we actually
support at the API level. (They're not synonyms; translucency means that you can
have pixels with nonintegral alpha values.)

> It looks like there may be more drawing surface memory churn since we no
> longer use global drawing surfaces and instead create them every time
> RenderViews is called....  Is that going to have any performance impact?  Or
> do rendering contexts do decent caching of drawing surfaces?

We already reallocate the drawing surface for double-buffering on every
RenderViews by calling GetBackbuffer, which caches on the platforms that need it
(Mac). Windows and GTK don't cache because caching is actually a performance
LOSE on those platforms (starves other apps of graphics memory). This patch
changes to always reallocate buffers for translucency, which will slow down Mac
translucency, but alleviate resource consumption on all platforms because we
usually don't need these buffers so keeping them around is wasting resources 90%
of the time.

In future GTK work (hopefully not too future) I want to move all the buffer
manipulation down into GFX where the Mac can manage its buffers however it likes.

> This is really oddly indented... Just make it three lines and indent all
> params equally?

OK

> Would a more descriptive name than "aRC" be in order for that argument?  Like
> "aCleanupContext" or something?

OK

> For that matter, make mBlender an nsCOMPtr and
>  mBlender = do_CreateInstance(kBlenderCID, &rv);

OK

> if (!rootParent)

OK, if you insist :-)

> >+  // XXX we should also set widget transparency for XUL popups that ask for
> > it
> Wouldn't that just work if you skipped the "toplevel document" check and set
> widget transparency for any widget whose view has no parent?

No, I think the view for a popup is parented normally in the view hierarchy.

> line saying that we need to set window transparency on toplevel windows with
> transparent backgrounds?

OK

> return canvasFrame ? ... : ...;
> should work fine, no?

Yeah. Maybe I'm too acclimated to Java, but I dislike the
treat-a-pointer-as-a-boolean style. But I'll do what I have to do to make you
happy :-).

More in the next comment...

Comment 80

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

> NS_ERROR, please.

OK

> Could we make the args match the comment a bit better?
> In particular, is aS1Image or aS2Image painted on white?

aS1Image. Sure.

> Hmm... Why the + 1?  Because we're looking at component #1 (as opposed to
> component #0)?
> If so, please move that comment up here....

Yep. OK.

> Should we just have one function that takes the "3" or "4" as an argument?

Yeah, sure.

> Hmm... Could you comment those two lines a little bit?
> Whence comes the magic number "8"?  Why are we doing that bitshift?

Sure. GREEN16 returns a value between 0 and 255 representing the green value of
the pixel. It only have BLEND_GREEN_BITS of precision (so the values are 0, 8,
16, ..., 248). The shift converts these to 0..31 by dropping the (8 -
BLEND_GREEN_BITS) low-order bits. We then scale the values up to the 0..255
range by multiplying by 255/31. If we just used the GREEN16 values directly in
the same equations that we use for the 24-bit case, we'd lose because (e.g.) a
completely transparent pixel would have GREEN16(pix1) = 0, GREEN16(pix2) = 248,
and the resulting alpha value would just be 248, but we need 255. So we need to
do this rescaling.

Hmm, now I see that this could be simplified to
      PRUint32 pix1 = GREEN16(*s1);
      PRUint32 pix2 = GREEN16(*s2);
      *aAlphas++ = (PRUint8)(255 - ((pix2 - pix1)*255)/(((1 << BLEND_GREEN_BITS)
- 1) << (8 - BLEND_GREEN_BITS)));
but that will still need a comment :-)

> All of this is using aNumBytes to mean aBytesPerLine; should it be called
> that?

Yes it should.

> This I do not like one bit... if this is legal, why are we bothering with
> nsDrawingSurface at al instead of just using nsIDrawingSurface?

Legacy code; we've been doing this on the Blend path for years. The whole
drawing surface API is broken. My plan is to first drive all uses of drawing
surfaces down into GFX, and then to changes uses of
nsDrawingSurface/nsIDrawingSurface to plain platform-specific APIs.

> Also, why are we losing the descriptive black/white names and using srcSurface
> and secondSrcSurface?

Legacy code copied from the Blend path. I'll fix that.

> What's the point of doing the rangeCheck if we're just going to use aRect here
> and below?

My mistake. I'll fix it.

> Hmm... Could we make the argument orders for ComputeAlphas and ComputeAlphasN
> (for various N) match as much as possible?

OK, I'll try.

> So if I call this on an <iframe>s widget, the transparency of the browser
> window that contains the <iframe> will be set?

Yeah. This is unfortunate but it avoids the need for layout to find the
nsIWidget for the top-level window, which is not trivial. I suppose I should
change this so that it only affects the current widget, and only if that widget
is a top-level nsIWidget (no parent); then layout will have to chase nsIWidget
parents to find the top. That's probably a nicer interface.

> File a bug to make nsPaintEvent have an nsCOMPtr member there, maybe?

OK

> This looks like sneak-over from your GTK over-painting patch....
> Which parts of this diff are actually relevant to this bug?

Oh dear, yes it is. Ignore the entire hunk at @@ -789,121 +795,82 @@.

> Tabs?  Please fix?

Legacy tabs :-). I will fix.

Comment 81

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

Attachment: complete patch

Revised patch addressing all bz comments as I promised.

I changed the comments on nsIWidget::GetWindowTranslucency to indicate that
indeed, it really sets the state of whatever toplevel window contains the
indicated widget. It's just too hard for XP code in layout to find the top
level nsIWidget for the window. Chasing widget->GetParent() doesn't work; it
seems that the nsIWidget parenting chain isn't fully hooked up.

Comment 82

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

Comment on attachment 117409 [details] [diff] [review]
complete patch

Throwing back to bz for approval.

Comment 83

[Boris Zbarsky [:bzbarsky]]

I'll try to get to this on Wed, but if I haven't by Friday then I won't be able
to until sometime in April....

Comment 84

[Jan Varga [:janv]]

Robert, I just noticed you added this to landing page.
I'm currently pretty busy with bookmarks branch. After that lands I'd like to
make  transparent chrome windows work on Windows (early 1.4 beta).

Comment 85

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 117409 [details] [diff] [review]
complete patch

>+   order. This array must be freed by the caller.

Uber-nit.  Make it clear that it must be deallocated with delete[].

>+  ResizeTransparencyBitmap(aWidth, aHeight);
>+
>   mBounds.width  = aWidth;
>   mBounds.height = aHeight;

Add a comment here that ResizeTransparencyBitmap needs the old bounds...

>+static PRBool ChangedMaskBits(gchar* aMaskBits, PRInt32 aMaskWidth, PRInt32 aMaskHeight,
>+                              const nsRect& aRect, PRUint8* aAlphas) {

Maybe MaskBitsHaveChanged ?

>+NS_IMETHODIMP nsWindow::UpdateTranslucentWindowAlpha(const nsRect& aRect, PRUint8* aAlphas) {
>+  if (mTransparencyBitmap == nsnull) {
>+    PRInt32 size = ((mBounds.width+7)/8)*mBounds.height;
>+    mTransparencyBitmap = new gchar[size];
>+    if (mTransparencyBitmap == nsnull)

if (!mTransparencyBitmap) in both places, please.

Looks good otherwise (though I have to trust pav on his review of the proper
use of some the X-guts...)

Comment 86

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

Fix checked in.

Comment 87

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

Apparently this caused the regressions in bug 198946 and bug 198983. It will be
backed out in a moment. I need to figure out why these regressions happened when
my debug build works OK. It could be opt vs debug. It's not classic vs modern,
because bug 198946 happens with classic theme on my laptop.

Comment 88

[Cathleen]

reopening.  I backed out the fix from darin's machine.  due to regression
blockers today. 

Comment 89

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

Attachment: revised patch

Here's a new patch that fixes the issues found with the last patch. Here are
the deltas from the last patch:

* Added some safety assertions inside ComputeAlphas to alert if we're
overrunning the alphas buffer. (These don't fire in my tests, but in future it
would be helpful to know if they do.)
* I recently added an optimization to GTK painting in nsWindow.cpp that stops
painting if the window is obscured. This needs to be disabled for translucent
windows, because a translucent window can be obscured just because all its
pixels are currently transparent, but we still need to paint it in case the
pixel alphas change.
* Changed the translucent-window-setting logic in nsContainerFrame so that it
enables or disables the setting every time the root view is synced. (Before we
just enabled it the first time the document looked transparent; this caused
problems when the document goes through a transient state where it is
transparent but is "really" opaque in the steady state.) Also changed this
logic so that it always only applies to XUL documents, never HTML (hidden
about:blank window was going transparent). Also added checks to fix the print
crasher.
* Added a warning to nsViewManager whenever we paint a translucent window. This
ensures we'll know if we turn on translucency by accident. I verified that this
warning never fires during normal operation.

Comment 90

[Alex Hosking]

Am i right in asuming this will be a big feture, espesially in the next Netscape
release?

Comment 91

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

Comment on attachment 119572 [details] [diff] [review]
revised patch

Reapplying for r/sr.

I think this should be landable in 1.4beta since the changes on normally
executed paths are fairly small.

Comment 92

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 119572 [details] [diff] [review]
revised patch

Looks fine.

Comment 93

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

Checked in again ... let's hope it sticks this time!

Comment 94

[Adam D. Moss]

Oh no.  I'm sad to say that I'm once again seeing some of the strange weirdness
that I was seeing with the last version of the patch.

Specifically, ^F to bring up the Find dialog brings up a titlebar and a
totally-transparent window the first time, works subsequent times (linux/gtkfe/x86).

Comment 95

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

strange. some dialogs work, others don't.

I'll see if I can get a fix for this today. If not, I'll back it out tonight.

Comment 96

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

Attachment: fix...

The problem is that we seem to occasionally paint a window when it's in a bad
state (no styles resolved). This is nondeterministic. The window element is
then transparent, which causes us to activate window translucency. And it seems
that once we've activated window translucency, GTK won't let us turn it off and
does strange things when we try.

On the other hand, we can't delay too long because if we set the window mask
for the first time after the window has been Shown, it won't take effect. (We
can change the mask though, as long as it was first set before the window was
Shown. Weird).

So the solution is to delay setting the window mask for the first time until
the window is shown.

Comment 97

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

Fix checked in. I hope this is it! No more transparent dialogs for me.

If this doesn't work, I'm backing the whole mess out and going to bed.

Comment 98

[Jim Dunn]

This check-in broke a couple of the ports tinderbox.
You declare "void ApplyTransparencyBitmap();" yet
you have it "return return NS_ERROR_FAILURE;" "if (!maskBitmap)"
and you don't check for any return code.

I am going to re-open this bug and just "return" if
the maskBitmap doesn't get created.  If this is "ok" 
then you can just close this bug again, otherwise, 
you can deal with it a different manner.

Comment 99

[Jim Dunn]

ok, bryner actually fixed this... 
I am just gonna reset this to fixed...

Comment 100

[Cathleen]

This check-in added 4k in codesize!
Is there anyway to optimize?

  Overall Change in Size
  	Total:	      +4364 (+7024/-2660)
  	Code:	      +4176 (+6832/-2656)
  	Data:	       +188 (+192/-4)
  
  libgklayout.so
  	Total:	      +2044 (+4556/-2512)
  	Code:	      +2048 (+4556/-2508)
  	Data:	         -4 (+0/-4)
  	      +2048 (+4556/-2508)	T (CODE)
  		      +2048 (+4556/-2508)	UNDEF:libgklayout.so:T
  			      +1280	nsViewManager::RenderDisplayListElement(DisplayListElement2 *,
nsIRenderingContext &, BlendingBuffers *)
  			      +1048	nsViewManager::RenderViews(nsView *, nsIRenderingContext &,
nsRegion const &, int &)
  			      +1040	nsViewManager::CreateBlendingBuffers(nsIRenderingContext *, int)
  			       +372	SyncFrameViewGeometryDependentProperties(nsIPresContext *,
nsIFrame *, nsStyleContext *, nsIView *, unsigned int)
  			       +224	BlendingBuffers::~BlendingBuffers(void)
  			       +224	ConvertNativeRegionToAppRegion(nsIRegion *, nsRegion *,
nsIDeviceContext *)
  			       +144	nsCSSRendering::PaintBackground(nsIPresContext *,
nsIRenderingContext &, nsIFrame *, nsRect const &, nsRect const &, nsStyleBorder
const &, nsStylePadding const &, int)
  			       +108	BlendingBuffers::BlendingBuffers(nsIRenderingContext *)
  			        +92	nsCSSRendering::FindBackground(nsIPresContext *, nsIFrame *,
nsStyleBackground const **, int *)
  			        +16	nsCOMPtr_base::nsCOMPtr_base(nsISupports *)
  			         +8	nsViewManager::nsViewManager(void)
  			         -4	atexit
  			        -24	global constructors keyed to
nsViewManager::DestroyZTreeNode(DisplayZTreeNode *)
  			        -56	__static_initialization_and_destruction_0
  			       -316	nsViewManager::~nsViewManager(void)
  			       -932	nsViewManager::CreateBlendingBuffers(nsIRenderingContext &)
  			      -1176	nsViewManager::RenderDisplayListElement(DisplayListElement2 *,
nsIRenderingContext &)
  	         -4 (+0/-4)	? (DATA)
  		         -4 (+0/-4)	UNDEF:libgklayout.so:?
  			         -4	__CTOR_LIST__
  
  libwidget_gtk.so
  	Total:	      +1568 (+1704/-136)
  	Code:	      +1376 (+1512/-136)
  	Data:	       +192 (+192/+0)
  	      +1376 (+1512/-136)	T (CODE)
  		      +1376 (+1512/-136)	UNDEF:libwidget_gtk.so:T
  			       +360	nsWindow::ResizeTransparencyBitmap(int, int)
  			       +312	nsWindow::UpdateTranslucentWindowAlpha(nsRect const &, unsigned
char *)
  			       +188	UpdateMaskBits(char *, int, int, nsRect const &, unsigned char *)
  			       +172	ChangedMaskBits(char *, int, int, nsRect const &, unsigned char *)
  			       +168	nsWindow::SetWindowTranslucency(int)
  			       +112	nsWindow::FindTopLevelWindow(void)
  			        +84	nsWindow::GetWindowTranslucency(int &)
  			        +36	nsWindow::~nsWindow(void)
  			        +20	nsBaseWidget::GetWindowTranslucency(int &)
  			        +20	nsWindow::DoPaint(nsIRegion *)
  			        +16	nsWindow::Resize(int, int, int)
  			        +12	nsBaseWidget::SetWindowTranslucency(int)
  			        +12	nsBaseWidget::UpdateTranslucentWindowAlpha(nsRect const &,
unsigned char *)
  			         -4	nsWindow::UpdateIdle(void *)
  			         -4	nsWindow::UnqueueDraw(void)
  			         -4	nsWindow::QueueDraw(void)
  			         -4	nsWindow::OnEnterNotifySignal(_GdkEventCrossing *)
  			         -4	nsWindow::NativeGrab(int)
  			         -4	nsWindow::Enable(int)
  			         -8	nsWindow::nsWindow(void)
  			         -8	nsWindow::IMEComposeStart(unsigned int)
  			         -8	nsWindow::IMEComposeEnd(unsigned int)
  			         -8	atexit
  			        -40	nsWindow::MakeFullScreen(int)
  			        -40	nsWindow::HideWindowChrome(int)
  	       +192 (+192/+0)	D (DATA)
  		       +192 (+192/+0)	UNDEF:libwidget_gtk.so:D
  			        +32	ChildWindow virtual table
  			        +32	nsBaseWidget virtual table
  			        +32	nsCheckButton virtual table
  			        +32	nsIWidget virtual table
  			        +32	nsScrollbar virtual table
  			        +32	nsWindow virtual table
  
  libgkgfx.so
  	Total:	       +752 (+764/-12)
  	Code:	       +752 (+764/-12)
  	Data:	         +0 (+0/+0)
  	       +752 (+764/-12)	T (CODE)
  		       +752 (+764/-12)	UNDEF:libgkgfx.so:T
  			       +372	nsBlender::GetAlphas(nsRect const &, void *, void *, unsigned
char **)
  			       +156	ComputeAlphas(int, int, int, unsigned char *, unsigned char *,
int, unsigned char *, unsigned int)
  			       +144	ComputeAlphas16(int, int, unsigned char *, unsigned char *,
int, unsigned char *, unsigned int)
  			        +92	ComputeAlphasByByte(int, int, int, unsigned char *, unsigned
char *, int, unsigned char *, unsigned int)
  			        -12	atexit

Comment 101

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

The layout changes, particularly the stuff in nsViewManager, were mostly code
reorganization that's necessary for other work (fixing our opacity model to
conform to CSS).

The GFX and widget changes are almost all #ifdef MOZ_XUL. Eventually embedding
should undefine MOZ_XUL and lose those changes.

Comment 102

[Jan Varga [:janv]]

Attachment: hidechrome patch

The hidechrome part of the fix got lost somehow.

Comment 103

[andreww]

Can someone point me to some info as to how to create and test examples of this?
 What do I need to do to get the examples to work?

Comment 104

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

Comment on attachment 119871 [details] [diff] [review]
hidechrome patch

just carrying forward r=bz from ages ago

Comment 105

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

andreww: try

mozilla -chrome http://bugzilla.mozilla.org/attachment.cgi?id=111901&action=view

Three caveats:
-- Only works on GTK right now.
-- Animation currently leaks X server memory. Not good.
-- There is a bug in nsBlender which means this will not work on displays which
use 24-bit color depth (crash). 16 or 32 bit depth is OK.

Comment 106

[Sergei Dolgov]

will look what it needs in BeOS port to be implemented

Comment 107

[Boris Zbarsky [:bzbarsky]]

roc, want me to file a bug on the 24-bit nsBlender thing?

Comment 108

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

mmm, sure, that would be great, especially if you've still got the patch

Comment 109

[Boris Zbarsky [:bzbarsky]]

Bug 202751 filed.

Comment 110

[rvj]

Can anyone clarify a minor point.

Is the window corner option dependent on the window background attribute being
set  to transparent. Currently with (1.4b), if a I specify a default window
color, the corner is not removed (unlike box elements, etc)

<window style="background:yellow;-moz-border-radius-topleft:20px;" />

in other words, am I correct in thinking that the above styling will work as
expected, once the background:transparent logic is ported ( currently using win 98)

Comment 111

[Brian King [:kinger]]

I can't get this to work either - Mozilla 1.4b or Firebird 0.6 - Win2000.

Comment 112

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

Brian, this has not yet been ported to Windows. See above:
> -- Only works on GTK right now.

I think I've fixed the leak I mentioned here:
> -- Animation currently leaks X server memory. Not good.

I'll fix this bug soonish:
> -- There is a bug in nsBlender which means this will not work on displays
> which use 24-bit color depth (crash). 16 or 32 bit depth is OK.

> am I correct in thinking that the above styling will work as expected

yes!

Comment 113

[Jan Varga [:janv]]

>>-- Only works on GTK right now.
I plan to work on the windows port in the near future.

Comment 114

[rvj]

This RFE has been marked as closed but is there still the intention to produce 
Windows support ?

I am really looking forward for this functionality.

I was also hoping to use the background transpancey to allow the creation of a 
titlebar widget which does not suffer from event capture problems outside of 
the visible window area.

Jan indicated in June it is planned but is there any timescale and what 
versions of Windows ?

Comment 115

[Jan Varga [:janv]]

(In reply to comment #114)
> This RFE has been marked as closed but is there still the intention to produce 
> Windows support ?
> 

We should probably file a new bug for windows port.

> Jan indicated in June it is planned but is there any timescale and what 
> versions of Windows ?
> 

Yeah, I was supposed to work on that, but the situation changed suddenly in July :(
If I only had time to work on this, sorry ...

Comment 116

[Dainis Jonitis]

Does the -chrome command line argument works in recent Mozilla trunk builds?
I've created alpha transparency code as a separate Win32 test application and
now I want to port it to Win32 nsWindow.cpp, but I can't find a way how to test it. 
When I pass test99.xul as a param the empty Mozilla window is opened with
standard chrome. When I open this xul in new window SetWindowTranslucency () is
called with false param. nsXULWindow::LoadChromeHidingFromXUL () does not see
"hidechrome" argument either. Seems that -chrome arg is just ignored.

Comment 117

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

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

Comment 118

[Brendan Eich [:brendan]]

So where's the new bug for the Windows version?

Dainis, how is it going?  Can you file the bug?  Thanks,

/be

Comment 119

[Dainis Jonitis]

Opened followup bug 252067 to implement translucent windows for Win32.

Comment 120

[Christian :Biesinger (don't email me, ping me on IRC)]

Bug 252525  filed for gtk2

Comment 121

[Nigel McFarlane]

This excellent work has some nits needing shakeout. See dependancies.

- N.

Comment 122

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

Nigel, this bug remains fixed. Regressions can stay in their own bugs. Thanks.

Comment 123

[Dainis Jonitis]

Bug 264708 adds 1-bit transparency support for Win9x and Win NT.

Comment 124

[Anand Aiyer]

Opened bug 307204 to add support for translucent windows in Mac