Closed Bug 228399 Opened 21 years ago Closed 20 years ago

background-color is mishandled when -moz-opacity is less than 1.0

Categories

(Core Graveyard :: GFX: Win32, defect)

Product:
Core Graveyard
Component:
GFX: Win32
Platform:
x86
Windows 95
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: fotemac, Assigned: emaijala+moz)

References

(
URL
)

Details

Attachments

(5 files, 4 obsolete files)

Screenshot of Bug228399.html with rv:1.6a
55.80 KB, image/jpeg
Details
Screenshot of Bug228399.html with rv:1.6b
56.03 KB, image/jpeg
Details
Videocard-probing utility
15.58 KB, application/octet-stream
Details
Patch v3
14.51 KB, patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review
Supplementary optimization patch v2.1
16.33 KB, patch
emaijala+moz
: review+
emaijala+moz
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.6b) Gecko/20031208
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.6b) Gecko/20031208

For all block elements that I've tried (div, h1, etc.), if one sets
background-color via a style sheet, inline style attribute, or the element's
style.backgroundColor object, the color is mishandled if one also sets
-moz-opacity to less than 1.0 via a style sheet, inline style attribute or the
element's style.MozOpacity object.


Reproducible: Always

Steps to Reproduce:
1.set a background-color by any means (see Details)
2.set -moz-opacity to less than 1.0 by any means (see Details)
3.

Actual Results:  
The background color for the element is mishandled (the element's
style.backgroundColor object reports the correct rgb values, but the document
displays something else).

Expected Results:  
The element's background color should be what is reported by the element's
style.backgroundColor object no matter what the object's style.MozOpacity value is.
What excatly do you mean by "mishandled"?
The backgound-color actually displayed for the element does not correspond to 
that specified by the rgb values.  The displayed color varies as you vary the -
moz-opacity value, and is correct only when -moz-opacity is 1.0.  Colors with a 
red component are the most severely affected.


reporter misunderstood what -moz-opacity was (dealt with by e-mail)
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
This bug report is not invalid and should not have been marked as resolved by
Ian. I have added a URL:

http://www.macridesweb.com/oltest/Bug228399.html

which illustrates the bug in Mozilla rv:1.6b (Gecko/20031208) and allows one to
see that it is absent in earlier Mozilla releases. Please assign this bug report
to someone qualified to deal with it.
URL: http://www.macridesweb.com/oltest/Bug...
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Aha! I now understand what you meant. Thank you for the testcase -- all display 
bugs should have them.

This is WORKSFORME on Windows 2000. Can you attach a screenshot? Does it only 
happen on Windows 95?
Assignee: general → win32
Severity: major → normal
Component: DOM: CSSOM → GFX: Win32
Screen shot of:

http://www.macridesweb.com/oltest/Bug220399.html

with Mozilla rv:1.6a (hue of background-color does not change with decreasing
-moz-opacity).
Screen shot of:

http://www.macridesweb.com/oltest/Bug228399.html

with Mozilla rv:1.6b (hue of background-color changes inappropriately as
-moz-opacity decreases).
Attachment #137464 - Attachment description: Bug220399.html with rv:1.6a → Screenshot of Bug228399.html with rv:1.6a
Attachment #137464 - Attachment filename: Bug220399_1_6a.jpg → Bug228399_1_6a.jpg
Yikes. Blender bug
Assignee: win32 → ere
Status: UNCONFIRMED → NEW
Ever confirmed: true
WFM on WinXP Pro. I guess we've started using something not supported under
Win95. Needs some digging.
WFM in Win98 too. Looks like a Win95 only issue.
Win95 OSR2 works too. I can't test the Windows 95 retail version as I didn't get
it to run in SVGA mode under VMWare.
It could be a graphics driver bug too. Reporter, which Windows 95 version are
you using? What is your video card? Driver version?
It's an old, store-bought (Staples) Compaq Presario 4860 with all of the
downloadable MS Windows Updates until MS stopped offering them for Win95. 
Control Panel|System|General reports "Microsoft Windows 95 4.00.95 B".  |Display
adaptors reports "ATI 3D RAGE PRO (English) (DirectX)" and |sound, video and
game controlers reports "ATI multimedia video driver"  No version numbers are
reported.  The monitor is an antique ZEOS Super VGA 800x600.
I can confirm the testcase from comment 4 on Win2000SR3, 16bit mode. I have seen
similar things on Win95B, 16bit. Both machines have an S3 videocard, Trio3D and
Virge respectivelly. Moz 1.7RC1 and Firefox 20040423.
Ah, and it is the same with CSS3 opacity: declaration.
Depends on: 241939
I installed the 2004-05-22 Mozilla daily build tonight, which has the Bug 
241938 fix. Bug 228399 persists unchanged with my Win95b system.

You probably meant 241939. That's not surprising. It is a bit different bug.

Anyway, when I changed the resolution to 24bit on the win95, S3 virge machine,
the colors were correct. This could be a 16bit only bug...

(In reply to comment #17)
> You probably meant 241939. That's not surprising. It is a bit different bug.

Yes.  Sorry about the typo.
 

> Anyway, when I changed the resolution to 24bit on the win95, S3 virge machine,
> the colors were correct. This could be a 16bit only bug...

Yes. That appears to be the case.  I changed Display | Settings | Color palette
to 32bit and that gets rid of the problem as well for the Gecko/20040522 nightly
build and for the Mozilla v1.6 milestone release on my Win95b.
(In reply to comment #14)
> I can confirm the testcase from comment 4 on Win2000SR3, 16bit mode. I have seen
> similar things on Win95B, 16bit. Both machines have an S3 videocard, Trio3D and
> Virge respectivelly. Moz 1.7RC1 and Firefox 20040423.

If you have this problem on your Win2000SR3 with 16bit, is the implication that
those who reported WFM with Win2000, Win98, or WinXP were not using 16bit, and
would also experience this bug if they switched to 16bit mode?  That is, was it
an incorrect inference that this is solely a Win95 problem?

No, I don't question the correctness of the tests of those people. They may be
right. I personally have 2 other machines (win98SE) on which I can't reproduce
this bug. As you can see from my comments, similarly to comment 12, I also think
this could be videocard specific. I pointed out S3 cards, you added ATI 3D rage
pro, which all are quite old cards (but not broken). It could just be a
coincidence, that such cards are used mostly in older win95 machines, therefore
nobody else can reproduce the bug on other OSes. Except me, cause I have a
win2000 with S3. I was not able to test this assumption because I don't have a
spare 16bit card I could plug into that win95. Could you make some test in this
direction? Try to change the card in your machine.

(The problem is, I have now tried the tests on another win98 machine with S3
Trio64V, and there are no problems...)

Anyway, if you say this worked correctly in 1.6a, then there is just some
regression and we shouldn't have to do such investigations.
> Anyway, if you say this worked correctly in 1.6a, then there is just some
> regression and we shouldn't have to do such investigations.

I'm not able to try other video cards, but the problem definitely was introduced
between the Mozilla v1.6 alpha and beta (Gecko/20031208) releases.  I had both
releases installed on my Win95b when I generated the above screen shots for the
bug report.  I still have Mozilla v1.4 and the corresponding Netscape v7.1
releases installed on my Win95b, and they do not have the problem.  But all
Gecko-engine browsers that I've installed on my Win95b since Gecko/20031208 do
have the problem, and for those I presently have (Mozilla v1.6 and v1.8a2),
switching from 16bit to 24bit or 32bit mode obviates the problem.
I am now using Mozilla 1.7 (Gecko/20040616) with Win98SE on an eMachine
(purchased in 2000) that came with a Compaq v410 monitor on RAGE PRO TURBO AGP
2X (English).  It also shows the blender bug when 16bit.
Creating a web page with opacity for the first time in maybe a year or so, so I
don't know when it stopped working, but this bug now makes opacity unusable for me.

I'm using Mozilla 1.8a4 on Win98SE, with an S3 ViRGE-DX/GX PCI card, and 16-bit
colour.
Ere, could the problem be the fact that nsBlender has a fixed idea of how 16-bit
colors are broken up into R, G, B channels? Can the mapping of colors into 16
bits change depending on the video card?
I don't remember. Maybe. But while this seems related to blender, there don't
seem to be any changes to it between 1.6a and 1.6n (31-Oct-2003 and
09-Dec-2003). Between those two dates I could only see (note: I could have just
missed something) two checkins that might be related to this problem: bugs
150881 and 212366. At least the changes in 212366 are quite extensive. I can't
see the problem so it's difficult for me to test if those changes make a difference.
(In reply to comment #24)
> Ere, could the problem be the fact that nsBlender has a fixed idea of how 16-bit
> colors are broken up into R, G, B channels? Can the mapping of colors into 16
> bits change depending on the video card?
The mapping can definitelly vary. I know at least one old DOS program, that
stored the order of RGB components in its configuration file for each card. I
think I have seen that it has defined the order as BGR (i.e. red and blue
swapped) for my card. I will check that and there also was some diagnostic
utility around, maybe I could post it here.

But, why are you using such low-level routines that need such precise hardware
info? Aren't there win APIs that abstract all this? Or would the blender be
painfully slow without this hardware optimization?
> Aren't there win APIs that abstract all this?

Partly. Some APIs could help in some situations but these APIs aren't available
in all Windows versions. Anyway the Windows API for transparency doesn't let you
do some of the things we need, like capture the alpha channel effects of regular
GDI calls.

> Or would the blender be painfully slow without this hardware optimization?

No, it's painfully slow as it is :-)
(In reply to comment #27)
> > Aren't there win APIs that abstract all this?
> 
> Partly. Some APIs could help in some situations but these APIs aren't available
> in all Windows versions.
Yeah, it seems transparency appeared in Win2000.

> Anyway the Windows API for transparency doesn't let you
> do some of the things we need, like capture the alpha channel effects of regular
> GDI calls.
Yes, but can't we render all this internally in neutral RGB and then let Windows
 dump the buffer onto the card (doing necessary RGB swaps)?

OK, so suppose you would know a way to ask the card which order of RGB
components it uses, would the blender be able to adapt to it? Without slowing
down too much :)
> Yes, but can't we render all this internally in neutral RGB and then let Windows
> dump the buffer onto the card (doing necessary RGB swaps)?

Hmm. Possibly.

> OK, so suppose you would know a way to ask the card which order of RGB
> components it uses, would the blender be able to adapt to it?

Yes.

> Without slowing down too much :)

No. But if we knew all the popular formats we could have code paths for each of
them.
This is the utility I talked about, and the output from it on my card. I don't
know if it can be used for something. Also, it probes VESA modes and I don't
know if Windows isn't using native graphics modes.
Could someone who sees the problem try turning off some or all of the hardware
acceleration Windows uses (as per
http://www.ati.com/support/faq/win95/win95configadjusthardwareaccelslider.html)
to see if it makes any difference? 
(In reply to comment #31)
> Could someone who sees the problem try turning off some or all of the hardware
> acceleration Windows

I dropped the Graphics Hardware acceleration setting from Full to None on the 
Win98SE system with Compaq Presario monitor and Compaq-supplied RAGE PRO TURBO 
AGP 2X video card.  The apparent blender bug persisted with no detectable 
improvement.

Note that although this is a WFM for Ere, to whom the bug has been assigned, 
Compaq was the major OEM for Win95, Win98 and Win2000 systems during the late 
1990's and early 2000's (until Dell overtook it), such that this bug can be 
expected to have made "opacity unusable" for a substantial number of Gecko-
engine browser users.  I don't know what OEM is associated with S3 Virge and 
Trio3D cards, which aceman and Val have reported also bring out the bug.

Regarding other recent comments, I'm puzzled by aceman's statement 
that "transparency appeared in Win2000" because -moz-opacity and 
style.MozOpacity worked fine on my Win95 and Win98 systems until the bug 
appeared at some point between Mozilla 1.6 alpha and beta (Gecko/20031208) 
releases.  Also, since aceman sees this bug on his Win2000 system with S3 
Trio3D, does this indicated that the bug is related to video cards but not to 
whether the Wintel system is DOS-based or NT-based (or was aceman referring to 
the DOS-based "Millenium Edition")?

I believe aceman was referring to the APIs introduced in Win2k. And I'm aware
that this problem might affect many people. Anyway, I'll continue trying to find
a change that might have caused this, but it's of course quite difficult for me
to try the changes. If there is someone who sees the problem and has Moz gfx
experience, feel free to help.
Keywords: helpwanted
Exactly, I said that there are OS APIs for transparency only since win2000. Of
course, Mozilla has its own implementation that works also on win95, using the
mentioned blender routine, that is buggy.

I am seeing this bug on real NT based Windows 2000 Professional. It is an IBM
branded machine containing a PII 400 and the mentioned S3 card. We have many of
them here.
(In reply to comment #34)
> Exactly, I said that there are OS APIs for transparency only since win2000. Of
> course, Mozilla has its own implementation that works also on win95, using the
> mentioned blender routine, that is buggy.

I see.  I wonder if the DOS-based "Millenium Edition" also has those OS APIs 
for transparency, but in any case, it will be years before the Mozilla 
developers could assume that all Wintel systems still in use do have them.

It's going to be tough to deal with this if the folks who can modify and 
compile/link the code do not have systems with Compaq or IBM supplied video 
cards which bring out the bug.  I guess the fact that the bug is specific to
16-bit mode and not the 24-bit or 32-bit modes should be a clue.  Would it be 
worth establishing whether this bug appeared in conjunction with the patches 
for Bug 212366 (i.e., provide an executable which has that backed out for 
testing by those of us who can see the bug)?

I don't know if this is a clue, but note that in addition to changing the hue 
(primarily by trashing the red component) reductions of opacity in post-rv:1.6a 
Mozilla browsers also impose a dot grid on the seme-transparent object.  Those 
who have the problematic video cards can see this most clearly in 

http://www.macridesweb.com/oltest/Bug228399.html

for the case with -moz-opacity set to 0.6.

Yes, it would be useful to see if those checkins caused this problem, but I'm
afraid backing them out might be difficult after such a long time and it might
need some manual work. If anyone is willing to take a stab at it, please do.
Otherwise I can try later.

I did some research and found out that it has been quite common to have
different number of bits assigned to different colors in 16bit mode. The typical
arrangement is 5-6-5 (R-G-B) which gives the most shades for green for which the
human eye is most sensitive, but there have been cards that do 6-5-5 or even
6-6-4. Blender doesn't take these into account and shuffling the values causes
interesting effects. Anyway, there have been no changes to blender during the
time this regressed, but maybe it's being utilized in a different way or something. 

I also noticed the dithering and I find that puzzling. Actually, the whole
interface looks like it's drawn in 8 bit color depth. At least I've never seen
the navigation bar background be so different from the background of the buttons
other than in 256 color mode.
(In reply to comment #36)
> I also noticed the dithering and I find that puzzling. Actually, the whole
> interface looks like it's drawn in 8 bit color depth. At least I've never
> seen the navigation bar background be so different from the background of
> the buttons other than in 256 color mode.

If you can see that dithering on your Wintel box (i.e., it's not WFM for 
you :), then it would seem not to be dependent on having an ATI RagePro or S3 
Virge/Trio3D video card and you could try to fix that problem.  Perhaps it's a 
different bug, but if our luck turns for the better the dithering and the 
apparent blender bug are co-dependent.  Or do you simply mean that you can see 
the dithering in the screenshot I posted?

Here's more info that may or may not be helpful.  At about the time that the 
apparent blender bug became evident, -moz-opacity and style.MozOpacity started 
working with embedded iframes.  I have an example of that in:

http://www.macridesweb.com/oltest/CrossFrame/

The iframe document has -moz-opacity:0.6 with a white background in a parent 
document with a grey backround, so that the iframe's background should become a 
lighter shade of grey.  Instead, with post-rv:1.6b Mozillas it's background is 
powder blue with that dithering (dot grid) on my Win98 system with an ADI 
RagePro video card.  That example also is using IE's alpha filter, which does 
work as intended for IE, and -khtml-opacity:0.6 for Konqueror and Safari, but I 
don't have those to test so I don't know what they actually do.

I do not see the dithering on the real testcase. I can only see it on the 3rd
rectangle (with opacity: 0.6) on the screenshot.

And please do not limit this to Compaq/IBM machines, those companies don't have
much to do with this. I just mentioned it so that it incidentally happens they
included such cards in branded machines and shipped them to large companies -
those companies would be largely affected by this bug. But the cards are normal,
I have bought one independently and stuck it into my noname homebuilt p200
machine. So the culprits are narrowed down to some models of S3 and ATI cards.

commnet 36: I still didn't get any explanation why Mozilla uses such lowlevel
routines, in which the order and size of color components does matter. It may be
faster, but is it even portable? Is it allowed practice to include such code?

Anyway, I proposed a solution in comment 28.
We probably do do something like this now:
1. render the needed region in memory, in the 5-6-5 RGB 16bit representation.
2. we write it directly to the card's memory. If the card doesn't expect 5-6-5
RGB, we have a problem.

My proposal was:
1. render the needed region in memory, in the 8-8-8 RGB 24bit representation.
2. call on OS API function Draw16BitRegion() that writes it to the card
appropriatelly.

Robert O'Callahan, do I see it wrong?
> apparent blender bug are co-dependent.  Or do you simply mean that you can see 
> the dithering in the screenshot I posted?

Yes, I meant I noticed the dithering in the picture. I haven't seen it myself.
Till now, this problem would appear only on rare sites using css3 opacity or
-moz-opacity. Therefore, most users don't come across it. But I now installed
Firefox 0.10.1 and it seems it is using the same routines for its UI. This may
make it a HIGH VISIBILITY BUG. The opacity is used atleast in the Extension
manager - disabled extensions are rendered behind some kind of 'fog'. This
screws up the colors in that block - e.g. the green puzzle tile is now purple.
I'll try building different trunk builds starting from 2003-10-30. Anyone who
sees the problem willing to test once a build is done? 
(In reply to comment #41)
> I'll try building different trunk builds starting from 2003-10-30. Anyone who
> sees the problem willing to test once a build is done? 

Yes.

A build from 2003-30-10 is now available at
http://www.kolumbus.fi/emaijala/moz-2003-10-30.zip . I can't keep it there for
very long, as the space is very limited. It's just the bin directory zipped so
unzip with directories somewhere and run Mozilla.exe from the bin directory.
(In reply to comment #43)
> A build from 2003-30-10 is now available at
> http://www.kolumbus.fi/emaijala/moz-2003-10-30.zip .

It's mozilla.exe does NOT have the apparent blender bug on my Win98SE with 
Compaq-supplied ATI RagePro video card.

Ok, good. Now there's a build from 2003-11-01 at
http://www.kolumbus.fi/emaijala/moz-2003-11-01.zip . Does this one have the problem?
(In reply to comment #45)
> Ok, good. Now there's a build from 2003-11-01 at
> http://www.kolumbus.fi/emaijala/moz-2003-11-01.zip.

It's mozilla.exe also does NOT have the problem.  So it seems the problem began 
at some point between 2003-11-01 and 2003-12-08.

A build from 2003-11-07 is now available for testing at
http://www.kolumbus.fi/emaijala/moz-2003-11-07.zip
(In reply to comment #47)
> A build from 2003-11-07 is now available for testing at
> http://www.kolumbus.fi/emaijala/moz-2003-11-07.zip

That DOES have the full problem (apparent blender bug plus dithering).

Ok, looks even more like the patch for bug 212366 would be causing the problem
here. Investigating.
http://www.kolumbus.fi/emaijala/moz-2003-11-07-2.zip is available for testing.
This version contains ugly hacks to make the blending always use 32 bit buffers.
Keywords: helpwanted
(In reply to comment #50)
> http://www.kolumbus.fi/emaijala/moz-2003-11-07-2.zip is available for
> testing. This version contains ugly hacks to make the blending always
> use 32 bit buffers.

The problem has been eliminated completely.  The hues are as intended and do 
not change with variation in opacity, and no dithering is apparent.
Attached patch Patch v1 (obsolete) — — Splinter Review 
Here is an initial patch against trunk to make blender use 32-bit bitmaps for
blending regardless of the screen depth. There are small changes to nsBlender
so that it doesn't ask for the depth from the device context and changes to
nsDrawingSurfaceWin to make it always use 32-bit DIBs when the surface is
locked for drawing. nsDrawingSurfaceWin::CreateBitmapInfo has been simplified
to always create the bitmap info for a 32-bit bitmap.
I'm not at all sure about the performance implications of always using 32-bit
buffers, but as the blending has always used DIBs, there are as far as I can see
only two places that make difference: Do32Blend vs. Do16Blend and SetDIBits
performance differences with different bit depths. With a quick glance I'd vote
for Do32Blend being faster. I've no idea of SetDIBits though. 

Btw, for me this patch makes blending work much better in 256 color mode. The
colors of the rectangles are of course wrong but at least they are visible
(without the patch I see only black rectangles).
Status: NEW → ASSIGNED
Comment on attachment 163994 [details] [diff] [review]
Patch v1

Roc, what do you think about this approach?
Attachment #163994 - Flags: review?(roc)
This looks like a great idea. But I think things would be slightly faster if you
could use a 24-bit bitmap. Can you do that?
PS, while this is all fresh in your mind, you might want to think about how we
could use ::AlphaBlend...
Attached patch Patch v2 (obsolete) — — Splinter Review 
This patch makes it so that at least 24-bit bitmaps are used. In 32-bit mode it
uses 32-bit bitmaps so that for example nsImageWin can use the alpha bits if it
wants to. Some tabs were also removed.

I'm keeping ::AlphaBlend in mind but don't want to mix it in before this works
otherwise well.
Attachment #163994 - Attachment is obsolete: true
I did some testing and found out that this would slow down painting in 16-bit
video mode considerably. This seems to be mainly because GetDIBits is _slow_ if
the depths don't match. SetDIBits doesn't take such a performance hit. This
might be because writing to a device is optimized and reads should be rare. I
tried caching the DIB, but View Manager trashed the effort by creating new
drawing contexts all the time. Need to think if there's something we can do
about this. 
Comment on attachment 164074 [details] [diff] [review]
Patch v2

I have some ideas I need to try. I won't give up yet.
Attachment #164074 - Attachment is obsolete: true
Attached patch Patch v3 — — Splinter Review 
This patch, in addition to what the previous one did, makes it so that an
offscreen drawing context is always created for pixel access. This actually
means there will always be a DIB holding the data instead of it being moved
back and forth between the DIB and the DC. I believe this will improve the
performance in other display modes too, but I have no real means to test it. In
16-bit mode the perceived performance on my system is at least on par with the
unpatched version.
Comment on attachment 164417 [details] [diff] [review]
Patch v3

Btw, the page I've tested the performance with is
https://bugzilla.mozilla.org/attachment.cgi?id=127505&action=view
Attachment #164417 - Flags: review?(roc)
Will this introduce a performance hit for 16-bit color machines, because of an
extra 24->16 bit conversion?
Because we could have the view manager determine whether blending will be
required and then tell gfx when it creates the backbuffer.
I don't think so. I've not done any timing tests myself but some others have and
it seems that usually GetDIBits is affected badly but SetDIBits is not.
Checked in. Waiting for results.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → FIXED
(In reply to comment #67)
> Checked in. Waiting for results.

It was included in the 1.8a5 nightly build with ID 2004110505 and still fully 
fixes the bug for my Compaq-supplied ATI RagePro video card.  Perhaps aceman 
will give us feedback for his IBM-supplied S3 video cards.

Unfortunately this seems to affect the performance of some DHTML animations a
little. I guess we need to have view manager tell gfx if pixel access will be
needed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Great, looks like some variation of my proposal was used :) Sorry, I can't test
it immediatelly, because I can't download the whole suite right now. But I'll
notify you when the time comes :)
Here's a supplementary optimization patch. nsIRenderingContext::GetBackbuffer
has a new parameter telling if the buffer is to be used for blending. The Win32
implementation uses this to decide if a buffer for pixel access is created.
After applying this patch at least gfx, view, content, layout and widget need
to be built.

With this patch I see performance equal to the version before patches on the
test cases I tried
(https://bugzilla.mozilla.org/attachment.cgi?id=127505&action=view and
http://www.zinn-x.com/parallax.htm)
Attachment #165175 - Flags: review?(roc)
Comment on attachment 165175 [details] [diff] [review]
Supplementary optimization patch v1

anyTransparentPixels isn't what you want. That just tells you that for some
reason we think some pixels in the dirty area aren't going to be painted.

What you should do is unconditionally execute this loop here that looks for
PUSH_FILTER display list commands:
http://lxr.mozilla.org/mozilla/source/view/src/nsViewManager.cpp#878
and record whether you see one; if you do, then there will be blending.
Comment on attachment 165175 [details] [diff] [review]
Supplementary optimization patch v1

need a new patch
Attachment #165175 - Flags: review?(roc) → review-
True, "oops". This patch corrects the mistake.
Attachment #165175 - Attachment is obsolete: true
Attachment #165713 - Flags: review?(roc)
Comment on attachment 165713 [details] [diff] [review]
Supplementary optimization patch v2

You need to change GetBackbuffer signature in nsRenderingContextGTK and
nsRenderingContextXlib.
Attachment #165713 - Flags: superreview+
Attachment #165713 - Flags: review?(roc)
Attachment #165713 - Flags: review+
Fixed signatures.
Attachment #165713 - Attachment is obsolete: true
Comment on attachment 166340 [details] [diff] [review]
Supplementary optimization patch v2.1

Carrying over r+sr.
Attachment #166340 - Flags: superreview+
Attachment #166340 - Flags: review+
Blocks: 271931
Optimization patch checked in and bustages (I forgot to add the new parameter to
calls to AllocateBackBuffer in gtk and xlib) fixed yesterday.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Depends on: 277762
This caused a Windows-only DHTML regression (painting-related?) in bug 277762
+    PRUint32 depth = (srcRowBytes / aWidth) * 8;

Shouldn't this have been srcSpan instead of srcRowBytes?
I can confirm the testcase from comment 4 is fixed in Deer Park A2 (Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050811 Firefox/1.0+) in my
Win2K box with S3 Trio3D.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: