74542 - table with background/transparent images not rendered properly

Status: RESOLVED INCOMPLETE

(Core :: Graphics: ImageLib, defect, P3)

Description

[Chris Picton]

Using build 200104221 on linux

Ref http://ftp.uskonet.com/test/test.html

The table images are set out as follows:

+----------+------------------------------------------------+-----------+
|   topleft|                  top                           |topright   |
+----------+------------------------------------------------+-----------+
|      left|                                                |right      |
+----------+------------------------------------------------+-----------+
|bottomleft|                  bottom                        |bottomright|
+----------+------------------------------------------------+-----------+

Under IE, the table is rendered correctly

Under mozilla, the corner images (topleft/topright/etc) are not fully rendered 
(some parts are left blank), and are not placed correctly within the cell.  The 
images top,bottom,left,right are not aligned correctly either.

Comment 1

[Boris Zbarsky [:bzbarsky]]

adding "display:block" (see bug 22274) to the images fixes the alignment of the
top,left,right,bottom cells.

The other problem (the corner images not positioned correctly) is still there. 
There basically seems to be some space between the images and the border of the
cell.  Posible imagelib problem?  (in that a part of the image is shown
transparent when it should not be).

Comment 2

[Keyser Sose]

This was fixed a couple days ago

WORKSFORME
Platform: PC
OS: Windows 98
Mozilla Build: 2001042304

Marking WORKSFORME

Comment 3

[Boris Zbarsky [:bzbarsky]]

I still see the problem with linux build 2001-04-23-08.  Linux-only bug...

Comment 4

[Boris Zbarsky [:bzbarsky]]

definitely an imagelib problem and a dup, but I can't find the original...

Comment 5

[Terri Preston]

I believe this is a dup of 50974 and I am marking it as that, if I am wrong, 
please reopen

*** This bug has been marked as a duplicate of 50974 ***

Comment 6

[Boris Zbarsky [:bzbarsky]]

reopening.  the images in question are gifs, not pngs.

Comment 7

[Jacek Piskozub]

Veryfying on existence of bug 81130 and bug 83087. However they are both dups of
bug 50974. Either they should be made dups of this one or this bug should be
reverted to a dup status, too (it was already a dup of bug 50974)

Comment 8

[Blake Ross]

Doesn't look like this is getting fixed before the freeze tomorrow night.
Pushing out a milestone.  Please correct if I'm mistaken.

Comment 9

[Chris Picton]

I just created a new test on the original page.

I took the gifs, converted them to pngs and made a new table using pngs

The table using pngs renders correctly, the one using gifs doesn't

Comment 10

[Stuart Parmenter]

.

Comment 11

[Stuart Parmenter]

Reassigning to nivedita

Comment 12

[Markus Hübner]

also see this on win-xp build 2002021108

Comment 13

[Nivedita (gone)]

Attachment: patch which partially fixes the gif

I have attached the patch which fixes the bug partially. The gif has image size
as 21*21, but the screen_width and screen_height are 24*24.  

The image was not getting correctly displayed because a frame of 21*21 was
being created for this gif. Hence to avoid this, in AppendFrame, I have addded
a check if the gif in non animated and it is the first frame, and if the screen
dimesions are greater than image dimensions then create a frame of screen
dimesions. But some how this is fixing the bug partially.

This patch also fixes the bug 113561, but partailly :(.

Comment 14

[Jim]

Err... yeah, horizontal alignment looks good now on the GIF version, but
vertical (strictly the top three images) is still off (ie, a gap). Also, and
this may just mean that I did something wrong of course, before the patch
(today's source) the GIFs had transparent bits, now they have black bits and a
handful of (regularly scattered) little coloured dots at the bottom. The latter
is probably a side-effect of the incorrect vertical alignment I suppose.

I'll try a 'make clean' and try it again (and retry without the patch to check
for blackness, for sanity's sake)

Comment 15

[Jim]

Well, it's not quite right, it definitely seems to have black (noise?)
background, where it should be set to the background colour, which I presume is
because of:
+          FillWithColor(mCompositingFrame, 0);
...without setting the fill colour first. Maybe.

Comment 16

[Nivedita (gone)]

.

Comment 17

[Vedran Miletic]

retargeting

Comment 18

[Boris Zbarsky [:bzbarsky]]

paper, any ideas here?

Comment 19

[Wayne Mery (:wsmwk)]

> Ref http://ftp.uskonet.com/test/test.html

testcase is gone

Comment 20

[Hermann Schwab]

bug is 7 years old, resolved WFM on Windows, testcase is gone 2 years ago, so I'm resolving this bug as INCOMPLETE/Linux only