125581 - PNG Transparency is messed up

Status: RESOLVED DUPLICATE of bug 125629

(Core :: Graphics: ImageLib, defect)

Description

[James Lariviere]

PNG Transparency is messed up.

Description:

Open a page with a semi-transparent png file and rendering results include: half
rendering or no rendering at all for WinXP or Linux for quite some time.

Steps:

Goto url.
Look at the sections.

Actual Rendering:
Some of the png's are rendered correctly in one section while partial or no
rendering in other sections.

I'll post a screenshot if not clear.

Expected Results:
The all the selected divs should have consistent semi-transparency.

Comment 1

[James Lariviere]

Attachment: Screenshot

Here is the screenshot.

I suggest also to select a alternate stylesheets, either by the Mozilla's menu
or click on the list on the page.  You can see that even when a new stylesheet
(alternate) is selected and the page is redrawn, mozilla does not render this
correctly in linux or windows.

Comment 2

[John Levon]

either bug 125484 or bug 125629 I think ...

For me linux cvs yesterday, the right box DOES have it, the left box
doesn't. selecting some text shows more of it.

Comment 3

[Ian Tommins ('thelem')]

Attachment: non-transparent png for testcase

Comment 4

[Ian Tommins ('thelem')]

Attachment: transparent png for testcase

Comment 5

[Ian Tommins ('thelem')]

Attachment: Testcase 1

When using this test case, do not click anywhere until the background image has
loaded.

The testcase contains two DIVs, one after the other. They are pretty much
identical, both have a 1px border (red for the first one, green for the second)
and have the background-image set (using css) to the same alpha transparent
png.

Expected behaviour (as seen in IE): The background image is wrapped
horizontally in both DIVs, but is cut off vertically because of the size of the
DIV. The DIVs look identical apart from the border colour and text.

Actual behaviour: The background image is shown in the first DIV and horizontal
wrapping is working correctly. However, the image is not cut off vertially. If
I increase the font size so that the first DIV can fit more than one of the
images in vertically, then the bottom copy of the image is not cropped.

Initially the second DIV does not show a background. However, if you highlight
the text and then click off, the correct background is drawn under the
previously highlighted area (this may be a lucky coincidence).

Also worth noting, on initial page loading the PNG is correctly aligned in the
first DIV. If you minimize and restore the window, then the PNG is drawn from
the top of the page (but you can only see the section inside the DIV). Equally,
dragging other windows over the DIVs produces the same effects as seen in bug
121230.

I will post some more test cases in the morning. I think this bug is closely
related to 121230 but is not a duplicate.

Comment 6

[Ian Tommins ('thelem')]

Attachment: Testcase 2

Similar testcase here. The top div doesn't have a background, the bottom has
the same, alpha transparent background as before. Spacing has been added at the
bottom to enable scrolling.

Drawing on initial loading is correct. When the entire window is hidden and
then reshown, the background PNG is drawn from the top of the window. If you
don't scroll down this will mean that you don't see the png being drawn at all
- only the bits which fall inside the area of the div are drawn.

After working through all this I realised this is more like bug 121230 that the
problem described above. I'll try to reproduce the problem above.

Comment 7

[Ian Tommins ('thelem')]

OK, I figured this one out finally (sorry for the spam).

In the url for this bug and in testcase 2, the background image in question is
being drawn to the correct height but at the top of the window.

In testcase 2, this can only be seen by reloading the page.

However, on the url, the div which is meant to have the background acts like a
window to that background. When it is over the area where mozilla is drawing the
background, it will show the background, when it isn't the background will be
hidden. Think of it like those magic pens that kids get - you write in invisible
ink and then when you colour over it in the correct ink it will show up.

I am marking this bug depends on 121230, because I suspect fixing that bug will
fix this bug too (and the testcases also exhibt 121230).

Issues NOT addressed by 121230 but addressed by this bug are:
 * The drawing of a background outside of the area required. (testcase 1)
 * The 'magic window' effect

Comment 8

[James Lariviere]

Even though bug 121230 was fixed you can still see that transparency is messed
up -- see Screenshot (attachment 69534 [details]).  In the screenshot, I've explained
where its messed up.  I know that IE doesn't support this but atleast it doesn't
render the png's currupted like mozilla does.

This is a regression.

Comment 9

[Brett Donald]

this could be a dupe of 123511

Comment 10

[Aaron Kaluszka]

no its not

Comment 11

[Aaron Kaluszka]

Err sorry... I think this is actually two bugs.  The URL seems to have bug
125629, but the testcases have bug 123511.  Dupe this against one of them...

Comment 12

[James Lariviere]

Marking dupe.

Does anyone know the cause of this regression?

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