Closed
Bug 225083
Opened 21 years ago
Closed 21 years ago
moz-icon urls show wrongly
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: Biesinger, Assigned: neil)
Details
Attachments
(3 files, 2 obsolete files)
685 bytes,
image/jpeg
|
Details | |
6.38 KB,
patch
|
emaijala+moz
:
review+
mscott
:
superreview+
|
Details | Diff | Splinter Review |
4.87 KB,
patch
|
Details | Diff | Splinter Review |
build from a few days ago, but with neil's patch for Bug 222694, shows
moz-icon://.htm?size=16 urls rather wrongly. I'll attach a screenshot
Reporter | ||
Comment 1•21 years ago
|
||
Reporter | ||
Comment 2•21 years ago
|
||
hm, I should've used a less lossy format than jpeg. anyway, the screenshot
doesn't make it much uglyer.
Reporter | ||
Comment 3•21 years ago
|
||
this was with 16bpp (1024x768, nvidia geforce2 ti)
Assignee | ||
Comment 4•21 years ago
|
||
What's going on here is that the icon channel is ignoring the bitfields on
16-bit bitmaps although the icon decoder can't handle them anyway...
Assignee | ||
Comment 5•21 years ago
|
||
I know this patch does no error-checking, but it should be good for testing.
Reporter | ||
Comment 6•21 years ago
|
||
hm, have you tried compiling this patch? I get
c:/mozilla/modules/libpr0n/decoders/icon/win/nsIconChannel.cpp(269) : error
C2039: 'biHeight' : Is no element of 'tagBITMAPINFO'
Reporter | ||
Comment 7•21 years ago
|
||
simply removing the line with that error and recompiling isn't exactly an
improvement
Assignee | ||
Comment 8•21 years ago
|
||
OK, so this way should ensure that I don't query for strange icon types.
Reporter | ||
Comment 9•21 years ago
|
||
this new patch does fix the bug
Assignee | ||
Updated•21 years ago
|
Attachment #135145 -
Flags: review?(ere)
Comment 10•21 years ago
|
||
Comment on attachment 135145 [details] [diff] [review]
Alternative approach
Change the compression to BI_RGB and add a comment about the required double
height. With these changes, r=ere
Attachment #135145 -
Flags: review?(ere) → review+
Assignee | ||
Comment 11•21 years ago
|
||
OK, so this fixes 16-bit and 32-bit displays by forcing them to 24-bit.
Assignee | ||
Updated•21 years ago
|
Attachment #135090 -
Attachment is obsolete: true
Attachment #135145 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #135184 -
Flags: superreview?(mscott)
Attachment #135184 -
Flags: review?(ere)
Updated•21 years ago
|
Attachment #135184 -
Flags: superreview?(mscott) → superreview+
Assignee | ||
Comment 12•21 years ago
|
||
Sigh... somehow I left out the double height code and comment...
if (GetDIBits(hDC, iconInfo.hbmColor, 0, colorInfo.bmiHeader.biHeight, buffer +
sizeof(ICONFILEHEADER) + sizeof(ICONENTRY) + colorInfoSize, lpBitmapInfo,
DIB_RGB_COLORS)) {
+ // doubling the height because icons contain two bitmaps
+ lpBitmapInfo->bmiHeader.biHeight <<= 1;
Assignee | ||
Comment 13•21 years ago
|
||
Updated•21 years ago
|
Attachment #135184 -
Flags: review?(ere) → review+
Assignee | ||
Comment 14•21 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•