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: