Closed
Bug 283343
Opened 19 years ago
Closed 19 years ago
GFX::nsBlender - wrong order of parameters may cause wrong color depth calculation
Categories
(Core Graveyard :: GFX, defect)
Core Graveyard
GFX
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: sergei_d, Unassigned)
References
Details
Attachments
(1 file, 1 obsolete file)
3.07 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
In <a href="http://lxr.mozilla.org/seamonkey/source/gfx/src/nsBlender.cpp#137">first ::Blend() method</a> of gfx/src/nsBlender.cpp RowBytes and Stride paramters are swapped in surf->Lock() calls and in following Blend() calls inside the method (compare to nsIDrawinSurface.h, if you wish). Also if () at <a href="http://lxr.mozilla.org/seamonkey/source/gfx/src/nsBlender.cpp#187">line 187</a> should use RowBytes instead spans. Not so nice, despite double bug results in (almost) proper work. But there is one issue with that - in <a href="http://lxr.mozilla.org/seamonkey/source/gfx/src/nsBlender.cpp#182">PRUint32 depth = (srcRowBytes / aWidth) * 8;</a> - as srcRowBytes here is actually filled with source span value, which isn't equal to to byte-width of rect-to-lock in common case. Rect may be smaller than whole backbuffer, and even if those are formally equal, actual span and byte-width may differ due to extra alignment bytes used in some case in pixmaps.
Reporter | ||
Comment 1•19 years ago
|
||
adding roc to cc
Summary: GFX::nsBlender - wrong order of parameters may cause wrong ccolor depth calculation → GFX::nsBlender - wrong order of parameters may cause wrong color depth calculation
Comment 3•19 years ago
|
||
This patch fixes bug 282080. However, on the Mac, I see the following assertion: ###!!! ASSERTION: Mismatched bitmap formats (src/dest) in Blender: 'srcSpan == destSpan', file /Users/pedemonte/builds/trunk/mozilla/gfx/src/nsBlender.cpp, line 186
Reporter | ||
Comment 4•19 years ago
|
||
2 Javier You are right. I put atention on real code, but forgot about assertions. spans in assertion must be replaced by row-bytes, as it was done for if() check. Will prepare updated putch. Anything else?
Reporter | ||
Comment 5•19 years ago
|
||
Changed one assertion, also it's text to differentiate it from next assertion and to reflect situation more exactly. Javier, please test this one, if you do it before February 28, and all is ok, I will set review request myself, but if you'll do it later, set r=? yourself, as i'm departing and afraid that first week in NYC i'll lack Internet access.
Attachment #175339 -
Attachment is obsolete: true
Comment 6•19 years ago
|
||
Sergei, this latest patch works just as well, and no assertion. Thanks.
Reporter | ||
Comment 7•19 years ago
|
||
*** Bug 282080 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 8•19 years ago
|
||
Comment on attachment 175557 [details] [diff] [review] patch - same as previous but assertion fixed i hope no more swapped parameters remained
Attachment #175557 -
Flags: review?(roc)
Attachment #175339 -
Flags: review?(roc)
Attachment #175557 -
Flags: superreview+
Attachment #175557 -
Flags: review?(roc)
Attachment #175557 -
Flags: review+
Reporter | ||
Comment 9•19 years ago
|
||
roc, hope someone checks that in, as i lack permissions outside BeOS-only code.
Comment 10•19 years ago
|
||
Comment on attachment 175557 [details] [diff] [review] patch - same as previous but assertion fixed checked in
Reporter | ||
Updated•19 years ago
|
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•