Closed Bug 74313 Opened 23 years ago Closed 23 years ago

Impossible to display an image at other than intrinsic size (can't resize dynamically or in <img> tag)

Categories

(Core :: Graphics: ImageLib, defect)

x86
Linux
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: bzbarsky, Assigned: tor)

References

Details

(Keywords: regression, testcase, Whiteboard: [imagelib] [linux scaling] wanted for 0.9.1)

Attachments

(5 files)

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.
Blocks: 66967
Blocks: autoresize
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".  
Severity: normal → major
Keywords: testcase
Summary: Impossible to resize GIFs in JS → Impossible to display a GIF at other than intrinsic size (can't resize dynamically or in <img> tag)
*** 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
Whiteboard: [imagelib]
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?
Whiteboard: [imagelib] → [imagelib] [linux scaling]
Summary: Impossible to display a GIF at other than intrinsic size (can't resize dynamically or in <img> tag) → Impossible to display an image at other than intrinsic size (can't resize dynamically or in <img> tag)
*** 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
Target Milestone: --- → mozilla0.9
Attached patch "fix"Splinter Review
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.
Status: NEW → ASSIGNED
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. ***
Keywords: patch
Blocks: 74548
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. ***
Keywords: mostfreq
The patch is missing scale.c.
Attached file 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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → 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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 80503 has been marked as a duplicate of this bug. ***
untargetting my reopened imglib bugs to investigate.
Target Milestone: mozilla0.9 → ---
*** 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.  
Status: REOPENED → NEW
Whiteboard: [imagelib] [linux scaling] → [imagelib] [linux scaling] wanted for 0.9.1
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. ***
Target Milestone: --- → mozilla0.9.3
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.
Keywords: regression
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. ***
Depends on: 83920
over to tor since 83920 will fix this
Assignee: pavlov → tor
*** 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.

Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
*** 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....
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: