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: