BUILD: linux build from 2001-04-01 STEPS TO REPRODUCE: Try to resize a GIF in JavaScript by setting it's width/height EXPECTED RESULT: The image is resized. ACTUAL RESULT: The image does not change size and parts of it go black. NOTES: Building with --disable-libpr0n fixes this behavior. So assigning to pavlov.

Does this also affect resizing images in Composer's image dialog?

Just tried composer. When the image is resized there (I tried a gif I had lying around) the box in the document is resized correctly but the image itself is not shown. You get an empty box. This affects both the image itself when a size different from the native size is specified and the "preview" thumbnail in the image creation dialog -- that thumbnail image is not present in builds with libpr0n enabled.

your build probably doesn't have XIE or gdkpixbuf so images arn't scaling.

Hmm. I _was_ trying this on an X server with no XIE. I just tried one with XIE and a simple testcase and I get the same results. I can't check composer right now due to bug 74707 Steps to reproduce: 1) Go to http://web.mit.edu/bzbarsky/www/Graphics/Dilbert/dogbert.gif 2) Type javascript:dump(document.getElementsByTagName("img").item(0).width=400) The image turns mostly blank and does not resize. I am certain that I have XIE -- xdpyinfo lists it, and I see the XIE_Flo crasher in libpr0n....

Works fine on MacOS

*** Bug 74861 has been marked as a duplicate of this bug. ***

Also works on MacOS, although I see odd garbage on the bottom of the larger ones (different bug).

Leston's testcase makes this "major".

*** Bug 75159 has been marked as a duplicate of this bug. ***

This error is also occuring on Irix

Pav, didn't you write a basic scaling funct for linux where we don't have everything installed?

I have tested this a bit mode. The problem Leston describes is indeed only present with no XIE. But even with XIE present we fail to properly resize GIF images with transparent backgrounds. bug 75351 filed on that issue.

*** Bug 75314 has been marked as a duplicate of this bug. ***

the summary's not quite accurate here - I see the same behaviour with JPEGs as well. It's a most irritating problem - it also affects <INPUT TYPE="IMAGE">, and breaks any page where someone's not quite got the image size correct. (the note about needing XIE - well, the RH6.2 boxes here don't seem to have this loaded by default. I'd guess there's rather a lot of boxes out there with this distro...)

[imagelib] - still happening on linux 2001041214

Added myself to cc-list. shouldn't this bug be nscatfood+? and have a target milestone of .9 (if that's feasonable ofcourse) or atleast 1.0?

*** Bug 75903 has been marked as a duplicate of this bug. ***

*** Bug 76658 has been marked as a duplicate of this bug. ***

pav is working on this. maybe for 0.9

ok, here is a patch... first thing: We always try and use XIE before gdkpixbuf. This is for 2 reasons... first because gdkpixbuf currently isn't scaling alpha masks and therefore makes images with alpha masks that are scaled look pretty dumb. Secondly, XIE should, in theory, allow the scaling to happen on the X server resulting in less data going back and forth between the client and server. second thing: try to use gdkpixbuf to scale... this is buggy and doesn't love me. third thing: do scaling using the data on the X server by doing XGetImage and XPutImage.. supports alpha masks, but is slow as shit running remotly with large images. most of this is from syd. it could probably be sped up locally by trying to use XShm*Image calls. four thing: this patch has code that should be able to take the client data and scale it... that code doesn't love me and doesn't work very well. feel free to make it better. this patch isn't perfect, but X not having scaling built in makes my life suck.

Is it worth checking this into the branch once it's cut and working on a better fix for the trunk? Or is this the best option we'll have for a while?

*** Bug 75768 has been marked as a duplicate of this bug. ***

*** Bug 75920 has been marked as a duplicate of this bug. ***

Wow, it's amazing to find out how many sites use scaled images ...

*** Bug 75105 has been marked as a duplicate of this bug. ***

The Xlib version is going to work fairly well for a majority of users. Those who are running X remotely however will want to set up their X server to support XIE (if not already set up).

*** Bug 74388 has been marked as a duplicate of this bug. ***

*** Bug 77143 has been marked as a duplicate of this bug. ***

*** Bug 75892 has been marked as a duplicate of this bug. ***

*** Bug 77174 has been marked as a duplicate of this bug. ***

The patch is missing scale.c.

tor@cs.brown.edu,blizzard@mozilla.org -- could you provide r= and sr= for this? Thanks.

[s]r=tor syd is looking at a faster implementation of the ScaleImageNN function. pav, file a bug about not scaling 8-bit alpha images properly.

77266 filed for 8bit alpha scaling

r=pavlov on syd's patch of the patch.. syd: can you r= the rest of it?

r=syd

a= asa@mozilla.org for checkin to 0.9

is there a bug filed on making the scaling stuff faster? syd? if not, lets get one filed. marking this one fixed.

This doesn't seem quite fixed yet (though it's getting there). When i open the testcase, none of the non-intrinsically-sized images are painted at first. The only way to make them appear is to scroll down (down only, not up), making the image's space disappear under the toolbar and then scroll back down. Only the portion of the image past which i have actually hidden is actually rendered (so there's no way to view such images near the bottom of the page). Resizing the window can make some of these images disappear again, too. (Again, only the non-intrinsically-sized ones.) Please reopen. (I don't seem to have the authority to do so.)

Sounds like bug 76046 to me, not this bug.

The problem i'm seeing seems to be a bit different from the behaviour seen on the URL for bug 76046. It differs in the following ways: 1. This problem effects only resized images (see testcase), while 76046 affects images in their intrinsic size (see URL at that bug). Load this bug's testcase several times, varying the window size. The behaviour is consistent: the instrinsically sized images render perfectly, while the resized ones appear only by first hiding them at the top of the pane by scrolldown. The URL for bug 76046 uses a large, intrinsically sized jpeg. 2. With this problem, the bottom of the image does not become visible by scrolling down, while this is the behaviour of 76046. In other words, in this bug, the hidden bottom part of the image seems to not be rendered at all, while in 76046 the hidden bottom part appears by scrolling. The behaviours seem different. I don't know if you want 76046 so subsume the behaviour i've described here. Does it appear likely that both bugs would be solved with the same fix?

there is a seperate bug for images not drawing the first time... i don't recall the number off the top of my head, but it is there in my vastly large bug list.

*** Bug 78228 has been marked as a duplicate of this bug. ***

*** Bug 80174 has been marked as a duplicate of this bug. ***

*** Bug 79919 has been marked as a duplicate of this bug. ***

*** Bug 79888 has been marked as a duplicate of this bug. ***

Still can't see the images C through F on linux build 2001052112

*** Bug 80503 has been marked as a duplicate of this bug. ***

untargetting my reopened imglib bugs to investigate.

*** Bug 78573 has been marked as a duplicate of this bug. ***

*** Bug 82610 has been marked as a duplicate of this bug. ***

Adding self to CC list. Any idea on a target milestone?

*** Bug 81713 has been marked as a duplicate of this bug. ***

*** Bug 82378 has been marked as a duplicate of this bug. ***

*** Bug 83098 has been marked as a duplicate of this bug. ***

Pav, have you had a chance to look into this? It's going to make 0.9.1 a rather unpleasand release for linux users.

Actually Asa the 0.9.0 release was much worse than this. libpr0n on Unix was basically completely unusable when it went in. Progress from there is slow, and Pav has other priorities. Is Linux an important platform for Mozilla? The 0.9.0 release says "No" and a lot of people heard it.

*** Bug 78700 has been marked as a duplicate of this bug. ***

Something odd is happening to the clip region of the rendering context. If you replace copyGC from the context with a gdk_gc_new() in nsImageGTK::DrawScaled() then the images are drawn as expected.

*** Bug 83456 has been marked as a duplicate of this bug. ***

*** Bug 83523 has been marked as a duplicate of this bug. ***

*** Bug 83312 has been marked as a duplicate of this bug. ***

Actually, i think mozilla's most important platform is linux. Since most webpages are made with IE in mind, i really dont think windows users are going to switch to mozilla. Netscape 6 arrived, and it sucked big time. Netscape 4.77 is there, but it's motif-based (ug) Opera is not really free, but ad-sponsored. So that gives me only 2 choices: mozilla and konqueror I think 0.9 is fine, but we are getting too many new bugs and regressions on this builds. I am currently using 2001053021 because it's the last version that autocomplete works, but it also breaks the delete key in mail. I posted bug 82278 corcening how slow mozilla renders images. http://www.digitalblasphemy.com/dbgallery/4/morninglight.shtml is an example I have been told this is an issue of this bug. Now look at this one: http://www.angelfire.com/hi/CristianCastro/ That chokes on my 1200mhz system This is really a major bug

*** Bug 83716 has been marked as a duplicate of this bug. ***

*** Bug 84810 has been marked as a duplicate of this bug. ***

*** Bug 84859 has been marked as a duplicate of this bug. ***

I've just deleted 0.9.1 (talkback) and downgraded to 0.8 due to this bug. Please change target milestone to 0.9.2, or even better: make a quick fix soon. You will lose some Linux users if this bug remains much longer.

Since this used to work, adding regression keyword.

petersen@netscape.com filed a parser bug that appears to be this. Bug 84782 Is it all parser, not imagelib?

It can't be all-parser, not least because the problem seems to be X11-only. 84782 sure looks like a dup.

*** Bug 84782 has been marked as a duplicate of this bug. ***

In imagelib there are at least two bugs causing these problems: 1) scaling too much 2) clipping rect is in wrong position I am working a patch for this.

the url in dup bug 83312 is a great testcase: http://www.sj-arena.com/ Notice how image clipping varies when one resize width of browser window.

*** Bug 81571 has been marked as a duplicate of this bug. ***

Have you noticed what happens when you put the mouse on top of the mozilla window of this bug? Notice the big black square caused by the <img> This is just weird...

*** Bug 85086 has been marked as a duplicate of this bug. ***

In my earlier comment I meant GTK/XIE - not ImageLib. For some reason XIE didn't respect clip origin so I had to use XChangeGC() function to set it. Also DoFlo() used wrong size for the source area which caused those blue images. Now I go to get some sleep before it is morning.

Wowsa :) Buildt with the patch and tested some dups. These are fixed: bug 74861, bug 75159, bug 75314, bug 75903, bug 75768, bug 75105 bug 74388, bug 77174, bug 83312 bug 76658 - URL is now a 404 bug 75105 - Page has changed - no image there anymore. Various result: Bug 77143: All images load, but a resized "blank.gif" shows as a black area. Looks like another bug. In other cases a 1x1 scaled gif gets an unintended outline ( for instance left side at http://www.arlut.utexas.edu/ )

Could you check 82278 with the new build as well?

There are still some issues with the patch testcase: http://211.9.115.254/text.html This is not entirely XIE's fault but that image should have transparent background.

Transparent animated gifs have black background: bug 77914 Transparent non-animated GIFs have black background after redraw: bug 83726

*** Bug 82529 has been marked as a duplicate of this bug. ***

*** Bug 83308 has been marked as a duplicate of this bug. ***

http://www.newsforge.net is another site where a 1x1 pix.gif used for scaling grey lines under stories get an outline - in this case the outline is visible on right and left side only. I think the fix in Asko's patch is correct though - merely revealing a few other little problems we weren't seeing till now.

on the other hand.. perhaps it shouldn't be checked in till the black transparent gif bugs are solved. http://industry.java.sun.com/ looks pretty bad.. huge black sqares scattered around on page.

*** Bug 85137 has been marked as a duplicate of this bug. ***

I think this is the bug I'm seeing... With 0.9.1 build on Linux (tar.gz downloaded from mozilla.org) and gdkpixbuf installed, I see all images scaling fine *except* any gif that has a transparent background, which just don't display at all. Is that this bug or something else? (I didn't think XIE was even used if gdkpixbuf was installed at runtime...)

With the 0.9.1 tar.gz from mozilla.org, this bug happens with transparent GIFs or PNGs. JPEGs scale fine (modulo a nasty performance hit on scrolling). I mentioned this in bug 84859 (as well as attached test case), which was marked as a duplicate of this one.

I reported the slow speed in scrolling on bug 82278

I just REOPened bug 75351 for the linux-disappearing-transparent-scaled-images issue. As far as I'm concerned it doesn't seem to match the symptoms described in this bug (which also covers JPEGs and non-transparent images), so hopefully it won't just get blindly DUPed. Probably there was a better bug to REOPen, but that was the best that I could find at the time.

Should fix those black transparent gifs.

Its possibly, that bug 85137 is duplicate of this... Expect one interesting moment... if you type http://www.amber-da.com.ua you can see in left down corner the image (animated) with current tempereture and time. This is the same image as in my test page writing for bug 85137 illustration. In this place image like whell. But in my example is not. And a differences is - in example where its not work all images are in table. I vas try to change hight and width attributes in image and its work whell... But in tables - not... Possibly my 85137 is a dupe... but...

Built with the new patch and running for an hour or so testing dups here: Images seem to now render perfect :))) Newsforge and Sun sites: former "black squares" are scaled correctly and transparent again. This seems ready for r/sr/a

*** Bug 84996 has been marked as a duplicate of this bug. ***

*** Bug 85052 has been marked as a duplicate of this bug. ***

Seems so. I pulled at around 21:30 and then patched with attachment 37942 [details] [diff] [review]

comments or r/sr= needed.

went to http://web.mit.edu/bzbarsky/www/Graphics/Dilbert/dogbert.gif and resized the gif with javascript. Works fine Linux 2001061306

http://www.sj-arena.com/ is still WAY broken :(

Francisco León: It renders perfect here with the patch. Which compiler are you using? (version too, please.)

I thought patch was in nightly's already (oops) Using 2001061306

could anyone with the applied patch from attachment 37942 [details] [diff] [review] try this url http://www.hehe.at/funworld/archive/bugzilla.html I've applied the patch to the nightly source (13 Jun 01) but something is screwd up here; the above url doesn't work; http://www.sj-arena.com/ seems to be ok; testcase from attachment 29872 [details] works partly while on the nightly binary build C through F do not render at all, with the patch applied D and F are rendered wrong (ie D shows the half picture, F shows a quarter) C and E are shown correct [well I guess I should "clean up" my system a bit ;) but anyway it would very helpfull for me to know if it works and the strange effects only happen here](sorry for the bad english 4AMversion %)

*** Bug 85821 has been marked as a duplicate of this bug. ***

Peter Bergt: With the patch the attachment 29872 [details] works for me. http://www.hehe.at/funworld/archive/bugzilla.html is showing different problem than the patch is trying to fix: WARNING: can't do 8bit alpha stretched images currently , file nsImageGTK.cpp, line 464 8bit alpha stretched images are NOT supported by Mozilla at this time.

Could anybody explain how is this bug related to bug 83920 (remove XIE)? The XIE support will be droped by XFree86 and it's using is deprecated by XFree86 team. libXIE is not included in current Red Hat Rawhide Linux (XFree86-4.1.0). This patches looks like still using XIE, is it appropriate to work on this as it looks now XIE will be dropped/removed from Mozilla?

Martin, bug 83920 has no recent (last few days) activity. We are up against a very tight deadline for 0.9.2, and if XIE is still going to be in Mozilla 0.9.2 then it needs the scaling patch before we get buried in DUPEs. Sometimes it is appropriate to check in a fix even though your crystal ball tells you that the code will get ripped out again in a week or a month - and this is one of those times.

(using latest CVS on GNU/Linux i386 with latest patch) At http://www.standaard.be there is scaled down image in the middle of the page. This image is still not rendered in the page. Opening the image seperately works fine. I already reported this elsewhere, but someone decided it was a dupe of this bug.

Regarding http://www.standaard.be/ if you mean f140601b.jpg, it renders OK here in linux builds both with and without the patch. I compared nightly 2001061308 and a current CVS with the patch, against what is visible in NC4.77: All show the same images.

the test case looks here like this http://www.hehe.at/mozilla/bugzilla-test-case.jpg (ie D and F don't render correct) nightly source (2001/06/13) with patch, gcc 2.95.2, glib/gtk 1.2.10 some warnings from mozilla: WARNING: alpha bitmask not scaled! , file nsImageGTK.cpp, line 487

I built with the patch, and tested some dups: bug 82378 http://www.sharkyextreme.com/ bug 81571 http://www.suggestafix.com/about.html These both worked well once I turned on the XIE extension in X. Without XIE (and I'm pretty sure I don't have gdk_pixmap), most of these are still broken with or without the patch. Is there another bug that covers the changes needed for the xlib version? Peter, I suspect that's the gdk_pixmap clipping problem you're seeing. Looks ok here. TGke, do you have the XIE extension turned on in your X server? xdpyinfo |grep XIE will show XIE if it's enabled.

about http://www.standaard.be I suppose I was still asleep when I tested that. The current CVS version with patch works fine, I haven't tested it without the patch, but I assume you are right. Sorry for the hassle.

So far, the patch in bug 83920 is working great for me on the various testcases in here. It doesn't need XIE or gdk_pixmap. I suggest trying it.

Yes, please take the time to test the patches in 83920. They are working really well for me as well and the more testing the better.

*** Bug 86046 has been marked as a duplicate of this bug. ***

*** Bug 86162 has been marked as a duplicate of this bug. ***

over to tor since 83920 will fix this

*** Bug 64590 has been marked as a duplicate of this bug. ***

*** Bug 80950 has been marked as a duplicate of this bug. ***

*** Bug 86512 has been marked as a duplicate of this bug. ***

Checkin for 83920 fixes this problem on the gtk port. Tested the test case included here and about a half-dozen of the dups. Closing.

Verified fixed, tested most testcases and they work, scaled image rendering is also faster My bug 82278 is now opened up and confirmed to get some performance issues fixed in scaled image rendering Build 2001061821

build 2001061823 All problems, was reported by me in bug 85137 witch was marked as duplicate of this bug are present in this build. It's dont fixed :( The perfect life of this bug all can see at my example, writen for my bug 85137 at http://www.amber-da.com.ua:8100/Mozilla_bugs/GraphicsTable/BadRenderingInTable.html Thats all... Possibly it was not duplicate of this bug ?

Bug 85137 looks to be a duplicate of bug 86600.

the URLs in bug 85137 work just fine with XIE and Asko Tontti's patch here. This is why i marked it dup of this. Later, XIE was ripped out and another patch applied instead, and this bug was resolved as fixed. That last patch is now in the official builds but obviously didn't fix bug 85137, several images appear as black with that fix. I hope remaining issues are covered in bug 86600. Reopening bug 85137 for re-evaluation.

url from bug 85137 and url from bug 75351 works fine here with the last patch from bug 86600

This testcase sometimes work and sometimes not (non-deterministic): http://kocour.ms.mff.cuni.cz/~macok/bug.html Load the page (should be OK for the first time) and then repeatedly hit Reload. Bottom lines of boxes are sometimes not shown. (1/2-1/3 of cases). Red Hat Rawhide Linux/20010619xx (nightly snapshot)

Martin, please open a new bug on this issue and post the number here.

So I filled Bug 86822 regarding http://kocour.ms.mff.cuni.cz/~macok/bug.html testcase.

Please also note that resized animated GIFs still don't display. I've filed a new bug for that under bug 86883. I have posted a test case for that at: <http://www.fizzylogic.com/users/bulbul/mozilla-bugs/Test_Case_for_Resized_Animated_GIFs.html>

@ Leston your test case works correct with the patch from bug 86600

Peter: try martin's testcase and report your results

on Martin's testcase most time the top line of the news box is missing and the vertical lines are missing on both boxes did reload it a few times but didn't get a correct box (I'll download the latest sources and will report changes on 86822)

Marking VERIFIED since the basic problem is fixed and the remaining issues are under different bugs.

*** Bug 88391 has been marked as a duplicate of this bug. ***

The testcase is broken in 0.9.2 on x86 Linux: only black borders show (no ebay logo).

I see them fine on 2001062823 (0.9.2)

Oops, the test case does in fact work fine in 0.9.2 on x86 Linux. I apologize for the brain damage. I usually surf with the "Accept images from the originating server only" preference checked; with images from other servers allowed, it works fine. Ah, the virtues of public humiliation....