Closed Bug 113561 Opened 23 years ago Closed 21 years ago

transparent images defined as background aren't rendern properly

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: c.mertins, Assigned: tor)

References

Details

Attachments

(5 files, 2 obsolete files)

Image that causes problems
96 bytes, image/gif
Details
testcase
350 bytes, text/html
Details
handle frame smaller than container
15.40 KB, patch
pavlov
: review+
bryner
: superreview+
Details | Diff | Splinter Review
21x21 image, 1 frame, size of 1x1 starting at 10,10
62 bytes, image/gif
Details
testcase for above attachment
215 bytes, text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.6+) Gecko/20011203 BuildID: 2001120303 I have a background image with a transparent part in it so that there the background color should shine through by Mozilla repeats instead the backgound image every 15px(or so) althought image is 1024x1 (x, y). Reproducible: Always Steps to Reproduce: nothing else than a page with a gif with transparent parts and a background color Actual Results: repeats the image Expected Results: let the background color shine throuh the transparent part
Christoph, could you possibly attach this image to the bug? I don't have any 1024x1 images on hand to test with....
request image
------------ html-tag <body class="objectFrame\" oncontextmenu="return false" background="icons/background.gif"> ---------------- used Style-Sheet body.objectFrame { background-color : #F1F1FF; color : black; font-family : "Arial", "Helvetica", "sans- serif"; font-size : 12px; margin-right : 12px; margin-left : 12px; margin-top : 12px; margin-bottom : 12px; scrollbar-base-color : #DDDEFF; scrollbar-arrow-color : #000000; }
Attached file testcase —
seeing bug on Linux too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
Severity: normal → major
Priority: -- → P3
Target Milestone: --- → mozilla0.9.8
resetting priority and milestone. These fields should be set by the developer working on the bug or by some person whom the developer allows to set these fields (eg the developer's manager). Others should not touch them. The reason is that the fields represent the developer's estimate of when the fix will be done and how important the bug is compared to other bugs assigned to the same developer. If you want to nominate a bug for being fixed by a particular milestone, use keywords (nominating this for 0.9.8).
Keywords: mozilla0.9.8
Priority: P3 → --
Target Milestone: mozilla0.9.8 → ---
Target Milestone: --- → Future
taking this from pavlov
Assignee: pavlov → nivedita
Keywords: mozilla1.0
not noted on mozilla classic macos/macosx
Depends on: 74542
Attached image Bigger transparent PNG (obsolete) —
Attached file Second test case (obsolete) —
This one exhibits the problem described for me.
I can consistently reproduce a similar problem on Win32 builds (last one I've properly tried is 2002021303) but never (recently at least) on linux builds (2002030108). Apologies for the PNG, it's a bit big but it was one of a very small number I had lying around. Try the testcase I've added Actual Results: puts image in the wrong location and renders one copy (across the background of all the tables); switch tabs and it may reposition the image and/or wipe the image from the background of one or more tables; scroll the viewport (if the window is small enough) and it repeats bits horribly (a 'stutter' on the scrolling code?) Expected Results: identical centred (transparent) background images in each.
Jim, Can you please test your test case against the patch attached for the bug 74542. So as to confirm this bug is dupe of bug 74542.
Sorry, no build environment for win32, so I can't test it
Jim, If you have Linux build, then you could try testing on it.
Holy multicoloured stripes, Batman! Well, that's certainly very different, but I get what look like random multicoloured (vertical) stripes on a black background now, it looked as before without the patch. I'm going to try a 'make clean' and rebuild and check without the patch again, as a sanity check.
Yeah, it's definitely still doing it. From the behaviour, I'd guess that the background is filled (or was never filled in the first place) by some data pointed to by an as yet undefined pointer.
.
.
Assignee: nivedita → pavlov
I don't know if this is a related bug or something seperate. I have a <div> with a class that should cause it to load a partly transparent PNG. The idea is to tint the blackground of the page so I can use black text. The page is http://www.inertgasdesign.com/ . It displayed properly in Mozilla 1.0, but broke in 1.1 (sorry didn't try any releases between), is still broken in 1.2b and I just tried a snapshot from Nov 25, which still shows the problem. If I refresh a few times the image will eventually show up tinting properly. It looks like this happens when the background image for the page loads before the <div> attempts to render.
Keywords: mozilla0.9.8
It is already the year 2004, mozilla 1.6beta is out, what is being done???!!!
So.. I'm not seeing a problem with the testcase in comment 10 (is that Windows-only?). As for the testcase in comment 4, the DEBUG_TILING printfs in nsImageGTK::DrawTile tell me: nsImageGTK::DrawTile: mWidth=7, mHeight=1 nsImageGTK::DrawTile((src: 0, 0), (tile: 8,8, 405, 17) 0x88795d0 So for some reason the nsIImage has an mWidth of 7, even though the imgIContainer reports the right width. tor, any idea what's up there?
Frankly, this sounds like an optimization to prevent painting pointless pixels for normal images, but it does break tiling...
The GIF in question has a logical width of 1600 but only seven pixels of image data located at (0,0). To save memory the GIF decoder creates the minimum size image required.
Perhaps the tiling algorithms should use the logical width for the tile offset, then?
Assignee: pavlov → tor
Is there a similar problem on the right hand side? ie. a gif defined at 21,21 with one frame that starts at 10,10 and is 1,1 in size?
sorry, I meant left hand side. For the full effect of this testcase, try moving a smaller window overtop the rendered page. If I remember correctly, the aXImageStart and aYImageStart in nsRenderingContextImpl::DrawTile are positions into the image where the renderer wants you to start drawing to (at destinations 0,0 position). So if DrawTile gets passed 5,5 for those values, we'd still have 5 blank spots on the left/top, and 10 on the bottom, left.
The testcase from comment 27 works fine with this patch on gtk. The patch adjusts the offset values in nsRenderingContextImpl::DrawTile to correct for non-(0,0) based frames. The only thing that I'm somewhat concerned about is a GIF where the frame spills outside the logical screen. Don't think tiling such an image is well defined, so our output should be ok.
Comment on attachment 138981 [details] [diff] [review] handle frame smaller than container Patch has been tested on linux, win32, macos, and os/2.
Attachment #138981 - Flags: superreview?(bryner)
Attachment #138981 - Flags: review?(bz-vacation)
Attachment #138981 - Flags: review?(bz-vacation) → review+
Attachment #73232 - Attachment is obsolete: true
Attachment #73234 - Attachment is obsolete: true
Tor, tt seems there are other problems with transaprent drawing in BeOS port. So probably i will submit solution, which pads tiles properly, but obscures bachground in some cases.
I need another testcase, different from http://bugzilla.mozilla.org/attachment.cgi?id=138996&action=view Namely, with real image in background, woth padded tiles over it. Instead simple background-color.
Attachment #138981 - Flags: superreview?(bryner) → superreview+
Checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 233646 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: