Closed
Bug 817356
Opened 11 years ago
Closed 11 years ago
resized images have a blue tint on big endian machines
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
FIXED
mozilla20
People
(Reporter: stevensn, Assigned: stevensn)
References
Details
Attachments
(3 files, 1 obsolete file)
5.03 KB,
patch
|
Details | Diff | Splinter Review | |
5.04 KB,
patch
|
Details | Diff | Splinter Review | |
1.35 KB,
patch
|
gw280
:
review+
|
Details | Diff | Splinter Review |
Bug 486918 added new image resizers from SKIA. Since this was enabled resized images on my ppc32 machine show up with a blue tint. The convolver code extracts the RGBA bits from each 32 bit pixel but doesn't take the endian order into account.
Assignee | ||
Comment 1•11 years ago
|
||
Updated•11 years ago
|
Status: UNCONFIRMED → NEW
Component: File Handling → ImageLib
Ever confirmed: true
Product: Firefox → Core
Updated•11 years ago
|
Attachment #687479 -
Flags: review?(joe)
Comment 2•11 years ago
|
||
Comment on attachment 687479 [details] [diff] [review] proposed fix. Detect that this is a PPC and set the BENDIAN then use that when extracting the bits Review of attachment 687479 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/2d/convolver.cpp @@ +206,3 @@ > if (has_alpha) > + accum[3] += cur_filter * source_data_rows[filter_y][byte_offset + > + A_OFFSET_IDX]; Can you just leave these all on the same line? @@ +231,5 @@ > // > // We only need to do this when generating the final output row (here). > + int max_color_channel = NS_MAX(out_row[byte_offset + R_OFFSET_IDX], > + NS_MAX(out_row[byte_offset + G_OFFSET_IDX], out_row[byte_offset > + + B_OFFSET_IDX])); Same line here too
Attachment #687479 -
Flags: review?(joe) → review+
Assignee | ||
Comment 3•11 years ago
|
||
Assignee | ||
Comment 4•11 years ago
|
||
Attachment #687479 -
Attachment is obsolete: true
Comment 5•11 years ago
|
||
Pushed v3 in https://hg.mozilla.org/integration/mozilla-inbound/rev/69b924c155b0
Comment 6•11 years ago
|
||
I would strongly recommend that the change to SkPreConfig.h gets a patch file added to gfx/skia/patches, or that this change be upstreamed to google's skia repo (or both!). Otherwise this change is at risk of being overwritten when we next update skia.
Assignee | ||
Comment 7•11 years ago
|
||
submitted for review upstream https://codereview.appspot.com/6900063/
Assignee | ||
Comment 8•11 years ago
|
||
This patch will add a patch file in gfx/skia/patches to alter SkPreConfig.h the next time we import upstream sources
Comment 9•11 years ago
|
||
Sorry! I was confusing SkPreConfig.h with SkUserConfig.h, and incorrectly figured it didn't need to have a separate patch.
Comment 10•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/69b924c155b0
Assignee: nobody → steve
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Comment 11•11 years ago
|
||
Apparently attachment #690255 [details] [diff] [review] never went through review in m-c nor commited, and neither upstream who didnt reply on codereview. Should it be unbitrotten and r?'ed ? Stumbled upon this while investigating why skia got broken on ppc again (see #849253)...
Assignee | ||
Updated•11 years ago
|
Attachment #690255 -
Flags: review?(joe)
Updated•11 years ago
|
Attachment #690255 -
Flags: review?(joe) → review?(gwright)
Updated•11 years ago
|
Attachment #690255 -
Flags: review?(gwright) → review+
Assignee | ||
Updated•11 years ago
|
Attachment #690255 -
Flags: checkin?
Updated•11 years ago
|
Attachment #690255 -
Flags: checkin?
See Also: → https://launchpad.net/bugs/1130857
You need to log in
before you can comment on or make changes to this bug.
Description
•