Bug 39693 - loading images blocks konqueror
Summary: loading images blocks konqueror
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml image part (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Simon Hausmann
URL:
Keywords:
: 29420 48508 50431 51836 55643 65629 71244 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-03-23 13:18 UTC by Norbert Andres
Modified: 2004-01-26 05:56 UTC (History)
14 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Norbert Andres 2002-03-23 13:13:09 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           khtmlimage
Version:           KDE 3.0.0 (3.0 rc4)
Severity:          normal
Installed from:    compiled sources
Compiler:          gcc version 2.95.3 20010315 (SuSE)
OS:                Linux (i686) release 2.4.10-4GB
OS/Compiler notes: 

I'm not sure if this bug belongs to konqueror or to khtmlimage:
When loading a big png files (maybe other formats too) the konqueror gets blocked:
e.g. got to www.mosfet.org/liquid.html and click on one of the screenshots and try moving the mouse while it's loading:
The cursor just jumps over the screen if it does at all.
I have a 1.1 GHz CPU so this shouldn't be a problem.
I use compiled source from 22.3.2002.

But anyway:
Thanks for the whole software package (everything else works really fine) keep up your great work!

Regards
Norbert

(Submitted via bugs.kde.org)
(Called from KBugReport dialog)
Comment 1 na77 2002-04-26 18:00:02 UTC
Version:           4.0 (using KDE 3.0.5 (CVS HEAD >= 20020412))
Installed from:    compiled sources
Compiler:          gcc version 2.95.3 20010315 (SuSE)
OS:                Linux (i686) release 2.4.10-4GB
OS/Compiler notes: 

I experience the same problem. Since this takes away all the fun surfing web-sites with many images I would see this bug at least as "grave" more likely "critical".
Right now I have to browser one for going to web-sites like www.kde.org (Konqueror cause there are not much pictures/images on there/ or just small ones) and one for going to pages like www.kde-look.org (Mozilla/Opera).

(Submitted via bugs.kde.org)
(Called from KBugReport dialog)
Comment 2 George Staikos 2003-02-20 05:26:27 UTC
*** Bug 51836 has been marked as a duplicate of this bug. ***
Comment 3 George Staikos 2003-02-20 05:27:02 UTC
*** Bug 48508 has been marked as a duplicate of this bug. ***
Comment 4 Stephan Binner 2003-03-04 13:24:22 UTC
Does this still happen for anyone with KDE 3.1? 
Comment 5 Pupeno 2003-03-04 14:24:28 UTC
It doesn't happen to me in KDE 3.1 branch. 
Comment 7 peterhudec 2003-03-22 21:51:46 UTC
This bug still happens here with KDE 3.1 SuSE 8.1 RPMs.
Comment 8 Jukka Tastula 2003-04-17 00:16:13 UTC
Still happens here, too, with KDE 3.1 debian/unstable packages. 
 
This exact same behaviour was there for a few days when 2.something was still the latest 
and greatest in cvs. Back then the fix had (IIRC) something to do with qt's usage of 
Xrender... someone put the evil code back in? Probably talking out of my arse here as 
compiling qt without xrender support changed absolutely nothing. (Of course that original 
bug was with qt-copy 2.something)  
 
It's clearly a bug in something X does because the whole system goes crawling because of 
this, not just konqueror. Explains why this doesn't seem to be very widely experienced 
problem... I guess it just doesn't happen with every driver (using mga g450dh + millenniumII 
in xinerama here). If it did it would've been fixed something like 6 months ago when it 
reappeared, right?-)  
 
Comment 9 Jean-Christophe Dubois 2003-09-04 00:59:05 UTC
I would agree with Jukka. Something is wrong in the interaction between khtml 
and X. top repports that X is using 95+% of the CPU and the next process to use 
something like 3% is konqueror. Kill konqueror or point it to a non graphic 
page and the system is back to normal. The symptoms are a bit similar to the 
ones described in bug 60316 or bug 23368. 
 
It would certainly be interesting to know if this happens only with certain 
graphic cards or if this is a generic problem. I am using Mandrake 9.1 with a 
Geforce 2 MX 400 and XFree 4.3. KDE is in verson 3.1.3 and QT 3 is version 
3.1.2. 
 
 
 
Comment 10 Sashmit Bhaduri 2003-09-15 03:22:48 UTC
I made a 6000x6000 jpeg with GIMP that was filled completely black with a few
lines drawn in the middle (~750k).


gqview took 3 seconds to load it - using /tmp/test.jpg
xv took 4 seconds to load it - using /tmp/test.jpg
kuickshow took 7 seconds to load it - using /tmp/test.jpg
konq-HEAD took 24 seconds to load it - using /tmp/test.jpg
konq-HEAD took 49 seconds to load it - using http://localhost/test.jpg
MozillaFirebird took 4 seconds to load it - using /tmp/test.jpg
MozillaFirebird took 5 seconds to load it - using http://localhost/test.jpg
opera 6.12 took 3 seconds to load it - using /tmp/test.jpg
opera 6.12 took 3 seconds to load it - using http://localhost/test.jpg
Comment 11 Mike 2003-09-15 03:27:50 UTC
Does it for me with 3.9.91 CVS 
Hopefully this will be fixed because it really bugs me and it really locks up if you are 
using KDE remotely over XDMCP. 
 
http://www.swrt.com/cpimages/443280.jpg 
Comment 12 Casey Allen Shobe 2003-09-20 01:16:23 UTC
I confirm this problem using CVS 20020915. 
 
I have a pretty powerful machine (2.4GHz p4 w/1Gb DDR400 RAM), and it still 
chokes up when loading large images.  I'm using a 64Mb NVidia card @ 
2048x1536x24bpp (using the nv driver that comes with X, not the proprietary one 
from NVidia). 
Comment 13 Sami Liedes 2003-09-20 21:50:10 UTC
Also happens with the radeon driver in XFree 4.1.*, 4.2.* and 4.3.0, at least 
under KDE 3.1.3 and IIRC earlier versions (haven't tried newer ones yet), so 
it's not NVidia specific. 
Comment 14 Maksim Orlovich 2003-10-07 00:08:16 UTC
*** Bug 65629 has been marked as a duplicate of this bug. ***
Comment 15 John van Spaandonk 2003-10-26 10:53:52 UTC
Still present in Mandrake 9.2 (KDE 3.1.4)
I like watching photography sites like dpreview.com and this is not
really possible with konq. Will become a big problem in KDE, with all
these people having digital cameras...

I swear if it were possible I would give all my 100 points for this bug!
But wait, I've got different email-addresses.... Hmmm. :-)
Comment 16 Oded Arbel 2003-10-29 00:43:20 UTC
Still happens with CVS-HEAD 20031028 (3.1.93).
I suggest marking Bug 60316 as a duplicate of this as it looks to me to be the same problem (overdoze of graphics and konqueror chokes X).

Weird thing, is that this happens even if the tab that is loading the graphics is not displayed ! hope it means something to someone as I sure as hell don't understand it.

My system is a P4 1.5GHz, 256MB, GeForce 2MX.
Comment 17 Tommi Tervo 2003-11-03 20:43:09 UTC
*** Bug 55643 has been marked as a duplicate of this bug. ***
Comment 18 Ernst Bachmann 2003-11-04 14:24:20 UTC
As stated in my original bug report (55643) this is not only a problem of konqueror. 
kuickshow & co behave the same way when confronted with large images.

I think the bug is that all those apps try to convert the entire loaded image in a XPixmap (stored in the X-Servers memory) for faster drawing. 

IMHO you need quite some changes to solve the problem completely:

1. patch/configure the X-Server to deny XPixmap requests that would hang/crash the system. X11 Runs with uid 0, so normal ulimit saveguards won't help much.

2. Fix QT so it handles QPixmaps more efficiently. Currently QPixmap::MemoryOptim seems to do the right thing, storing the pixels in the applications memory space, but only for pixmaps with width <=128. (which, btw, seems completely wrong to me, cause you usually want the small, often-used pixmaps in the X-Server for fast display...)

3. Fix the applications to use QImage instead of QPixmap for large images. Of course that would make drawing much slower on remote X11 displays, but its allways better than a crashed system or your harddisk having to swap in/out hundreds of megs...
Comment 19 Dik Takken 2003-11-11 17:28:48 UTC
In my opinion, the problem has become even worse in KDE 3.2 Beta 1.
Comment 20 Ernst Bachmann 2003-11-11 19:22:01 UTC
Bug #53829 seems to have the same cause, I suggest merging it.
Comment 21 jaa 2003-11-14 03:32:57 UTC
This is happening also here, with KDE 3.1.4 (from gentoo). 
http://www.dpreview.com/ or http://www.imaging-resource.com/ are unusable with konqueror because of that. Pictures from those sites will block and freeze konqueror __and__ the whole desktop. And this is dual AMD64 Opteron with 2GB memory... =(.
With Gimp those pictures will be loaded like in one second.
Comment 22 Philippe Rigault 2003-11-14 07:42:07 UTC
I am not trying to excuse this bug (which is critical because it cripples the desktop), BUT:

It makes no sense to me to view large images (anything larger than the screen resolution for that matter) in the embedded konqueror viewer, which lacks the essential features for viewing a large image (auto-sizing/zooming/panning).

The workaround (actually, the right thing to do IMHO) is therefore to view images with an external image viewer (e.g kuickshow).

Concerning the embedded viewer, it would be nice to have an option for the maximum size image allowed in it (defaulting to the screen size for example), since viewing small images in it works well and makes sense. Anything above this size would either spawn the external viewer (if one is configured) or abort loading altogether. This would take care of the problem for now, until the resource hog is fixed. It would require reading the image header (very small, so this would be negligible in terms of time) into a temporary buffer until the size is known, and then make a decision.

>As stated in my original bug report (55643) this is not only a problem of konqueror. 
>kuickshow & co behave the same way when confronted with large images.

No, kuickshow is fine (I have here kde 3.1.3, 3.1.4, 3.1.92, 3.1.93 and all work fine).

In fact, kuickshow is more than fine: it loads the image two to three times *faster* than gimp (gimp 1.2.5 & 1.3.22).

Take this 6 Mpixel image: http://img2.dpreview.com/gallery/canoneos10d_samples1/originals/030316-1027-13.jpg
Loading time on Athlon MP1800+:
  kuickshow	0.8s :-)
  gimp		2.5s
  photoshop	2.0s

Comment 23 Vedran Ljubovic 2003-11-14 09:10:09 UTC
>The workaround (actually, the right thing to do IMHO) is therefore to view images with an external image viewer (e.g kuickshow).

You're assuming that I know whether next link contains a large image or not, which I usually don't. Also, Kuickshow can't really be used for HTML slide shows (one large image and previos/next links in the bottom).
Comment 24 Philippe Rigault 2003-11-14 09:45:06 UTC
>You're assuming that I know whether next link contains a large image or not, which I usually don't.
No, I don't assume that. All I am saying is :
1. For now (until this bug is fixed), having *all* images (that is MIME type is image/*) viewed in an external viewer is the only safe route. If the image happens to be huge, it turns out that this was the most sensible thing to do anyway (it autoscales in kuickshow, so the first thing you see is the entire image, which makes sense, and you can then zoom/pan easily). If the image is not huge, no big deal either. Remember, this is an *image* not an HTML page containing an image, so it is not clickable, and therefore ther is no benefit to view it in the embedded viewer.
2. I suggest a wish for the embedded viewer to *automagically* determine the size and act accordingly, which would lead to more user configurability.

> Also, Kuickshow can't really be used for HTML slide shows (one large image and previos/next links in the bottom).
HTML slide shows are composed of HTML documents (possibly with images in it), not simple images.
In a true slide show, you are not usually producing slides ten times bigger than your screen and use scrollbars to show features. Rather, you produce slides that *all* fit in the screen, so the images are downsampled to fit on screen. It does not prevent you, if you want to show dynamically some features in a downsampled image before going to the next slide, to link the image (not the Next button) to a bigger image (not HTML page), which will open in a separate viewer. Once you are done viewing the big image, close it and click on Next to go to the next slide.
Comment 25 Vedran Ljubovic 2003-11-14 11:01:11 UTC
Yes, but I'm also having problems with images that can fit in the screen, and with pages that contain many smaller images. Konqueror doesn't hang but it becomes really slow and takes too much cpu. Very large images above are merely extreme examples for debugging purposes.
Comment 26 Oded Arbel 2003-11-14 11:45:13 UTC
Subject: Re:  loading images blocks konqueror

> >As stated in my original bug report (55643) this is not only a problem of
> > konqueror. kuickshow & co behave the same way when confronted with large
> > images.
>
> No, kuickshow is fine (I have here kde 3.1.3, 3.1.4, 3.1.92, 3.1.93 and all
> work fine).

Kuickshow is not fine. its much more reasonable, it loads very fast, and it 
starts by scaling the image so you don't suffer the 'consequences" of loading 
a big image right out front. 
I tried to load the sample image you provided (Duron 700, 256MB memory, 1GB 
swap), and it indeed loads very fast and looks nice. I then zoomed into to 2x 
original size and then tried to do something else - my usually very 
responsive system took its sweet time to render each window I tried to load - 
it took about 20 seconds to render KMail (which I use to read mail) while 
normally its has almost no redraw lag. top showed X to gobble up 230MB (while 
kuickshow a close second with 80MB). shutting down kuickshow and X went down 
to just over 150MB (which is still more then what it used to be, but its 
mostly swapped out - only about 10MB resident - so I don't mind).

I'm not saying Kuickshow needs to be fixed - the method of storing the images 
in X is very fast for scrolling, and even on my very weak system its still 
reasonably behaving (I consider the above described behavior to be reasonable 
for the task that was done), but I don't think konqueror should use the same 
method: 
With Kuickshow I'm only displaying one or two images at a time so the load on 
X is not that bad and even so I'm mostly just looking at images and will 
close kuickshow once I'm done.
With konqueror I'm loading many many images at the same time, I'm doing a lot 
of different things while this is going on (tabbed browsing anyone ?) and 
images are expected to be displayed a long time while I'm busy doing other 
stuff (waiting for the other images to be loaded, writing an email to the web 
master, etc'). I think that konqueror should be changed not to use the same 
method as Kuickshow but store images internally where they don't load the X 
server. if I'm doing lots of scrolling on a single image and its too slow for 
me, I can always right-click it and choose "open with Kuickshow".

Comment 27 Sashmit Bhaduri 2003-11-21 03:08:44 UTC
Hmm.. kuickshow is as slow as Konqueror with very large nearly blank JPEG images for me. latest qt-copy with applypatches done.
Comment 28 jsvrp.gw 2003-12-11 02:14:50 UTC
I'm using KDE 3.2 beta 2 and I don't have any problems opening large images in Konqueror or Kuickshow.

Are you sure this bug cannot be CLOSED.

Cheers,

Jeroen
Comment 29 Niek van der Maas 2003-12-11 09:12:29 UTC
Jeroen, are you sure about that? I'm running KDE from CVS, and loading big images is still slow. Loading really big images crashes Konqueror and sometimes KDE or X. For example, try to click this link in Konqi: http://crew.tweakers.net/Renegade/yadiebla7890534.jpg
Bye, Niek.
Comment 30 Jo Øiongen 2003-12-11 09:45:16 UTC
Loading images for me have never crashed :-) But the last posters link gives an image thats renders wrong in konqy. It gets dragged horizontaly. And the computer responds slow while loading but acts fine afther.

Cheers Jo
Comment 31 Mike 2003-12-11 11:19:06 UTC
Konqi: http://crew.tweakers.net/Renegade/yadiebla7890534.jpg 

Link causes whole computer to come to a crawl, mouse cursor skips. 
KDE 3.93 
Comment 32 Oded Arbel 2003-12-11 12:55:32 UTC
Subject: Re:  loading images blocks konqueror

Comment 33 Jo Øiongen 2003-12-12 10:21:20 UTC
Will some one with the rights to do so pleas check bug number 29420 to see if it is a duplicate of this bug? (Also see bug number 26314 wich allready is marked duplictae of 29240). And if you agree with me, mark it as such :-)

Cheers Jo
Comment 34 Florian Evers 2003-12-13 19:18:29 UTC
> ------- Additional Comment #31 From Mike 2003-12-11 11:19 ------- 
> Konqi: http://crew.tweakers.net/Renegade/yadiebla7890534.jpg 

I tested the link with KDE 3.2beta2, and it locked up my whole desktop.

In "normal day usage", konqueror does block very often when loading images even in the latest beta (3.2beta2). When working with thunbnail previews in webpages, I usually open the images via "open in new tab" to load the pictures asynchronly in the background tab, but konqueror freezes very often for some seconds until the picture was loaded completely. Very annoying :-(
Comment 35 Jesper Juhl 2003-12-15 00:41:51 UTC
This bug is most deffinately still present in 3.2beta2 (aka 3.1.94).

I've encountered this often when just doing random web-page visits and stumble on pages with large images... They don't have to be larger than the screen (I'm running at 1600x1200), they just have to be resonably large (like 1000x1000) and/or in sufficient number.. The test images provided above show the problem for me quite consistently.

Wouldn't it be possible to take a look at the size of an image in konqueror and use a different method of showing it if it was deemed "too large" (file size or dimension wise) ?   

One thing is certain; current behaviour is annoying as hell, and a solution must be possible since mozilla and netscape don't seem to have these problems ...

Comment 36 Maksim Orlovich 2003-12-26 15:51:33 UTC
*** Bug 71244 has been marked as a duplicate of this bug. ***
Comment 37 John Firebaugh 2003-12-28 19:51:49 UTC
*** Bug 50431 has been marked as a duplicate of this bug. ***
Comment 38 Tertius 2003-12-29 13:03:11 UTC
Looks like I encountered the same bug. Konqueror gets hogged when it loads some pictures. But in my case there are some differencies which make me wonder, if that?s indeed the same thing.

I was able to identify a certain pic which always causes the problems described above. (I guess there are more, but this one I found.)

1. The picture which causes the "blocking effect" resides on my harddrive and its not an oversized JPG. (Size: 1136 x 856 Pixel, 776,9 KB) The effect appears when Konqueror tries to produce a thumbnail for this picture. The pic is shot with my digital camera and then manipulated with photoshop6. 

The "blocking effect" was caused on two different machines, both with SuSE9.0 + Knoppix 3.3.

2. In the same directory are 30 other pics of the same origin, with sometimes bigger size and with the same history and none of them causes this "blocking effect". 

Therefore I opened this pic in gimp and saved it without changing it under a different name in a different folder - and the "blocking effect" was gone! Konqueror could render a thumbnail for it in a wink.

It seems to me, that the filestructure of a pic has an influence on whether Konqueror is able to open a file without problems or not.

I?ve uploaded the incriminating pic to this address:
www.die-patrozinien-roms.de/test/bild14.jpg

I hope this helps to investigate the problem. Btw. my machine is 1GHz Athlon, 400MB Ram - but if the effect strikes, it is out for minutes - if Konqueror or KDE doesn?t crash before.

Comment 39 Dik Takken 2003-12-29 13:16:10 UTC
> Therefore I opened this pic in gimp and saved it without changing it under a different name in a different folder - and the "blocking effect" was gone!

Did you save the image as 'progressive' JPEG, like the original?

Your JPEG image does block my machine as well, but not as heavily as other images that I have seen. The box (800 MHz Athlon) is still usable.
Comment 40 Tertius 2003-12-29 13:28:50 UTC
The version of the pic which causes the trouble was saved with photoshop as jpeg and I don't recall whether photoshop does this per default as progressive. The version I saved with Gimp was certainly not saved as progressive - that I can tell.
I will check the "save settings" in Photoshop whats the default here.
Comment 41 Dik Takken 2003-12-29 13:47:21 UTC
You did save as progressive in Photoshop, you can see that by looking at the way the image is rendered - progressive. The fact that you did not save it progressively with the Gimp is probably the reason why the problem disappeared.
Comment 42 Tertius 2003-12-29 14:14:44 UTC
Hm, all the other pictures in the directory are saved the same way as well - but none other caused this trouble. I know there must be some other offenders in other directories, since I experienced these "blocking effects" since my "migration" from SuSE 8.1 to 9.0. I just didn't brought this in connection with this particular problem yet.
But the files in the same dir are all ok - and they went through exactly the same process, i.e. they are `progressive` JPEGs.
Comment 43 Oded Arbel 2003-12-29 14:42:00 UTC
This last image actually does not block my konqueror at all. there is some slow down while the image is being downloaded and rendered, but its gone once its fully downloaded and it does not exist at all if I'm downloading it in a background tab. 
In the original problem, the fact that the image is loaded is what causing the slow down, and its a disaster not the mild hickups I get with your picture.

I'm guessing that your problem might be with the thumbnail generator that for some reason does not like that picture specificly, but I can't verify this as on my computer the image preview isn't working - don't know why.
Comment 44 Vedran Ljubovic 2003-12-29 20:18:31 UTC
A similar problem (but the subject is "loading images blocks konqueror" and I don't feel like opening a new bug). Look at this page:

http://forum.lugbih.org/posting.php?mode=smilies

It's a standard PhpBB page showing all of the available smilies. It has around 100 smilies of which some are animated. As the page loads, animations slow down and eventually stop. Other Konq windows become slow too. Mozilla animates them fine.
Comment 45 Simon Perreault 2003-12-29 20:30:49 UTC
This is a regression and is not related to the current bug. This bug does not happen in 3.1.4. See that when you resize the window, the animations continue. You should open a new bug, if it does not already exist.
Comment 46 Dirk Mueller 2004-01-10 09:22:21 UTC
Subject: kdelibs/khtml

CVS commit by mueller: 

* rendering/render_image.cpp/.h: Reduce X-server pressure with large images 
(#39693).

* misc/loader_jpeg.cpp: Upon suggestion from Maksim, implement decoding of
nonprogressive jpegs in non-buffered-image mode. This massively reduces memory
footprint and slightly improves performance. 

You, you most hated Konqueror bug, eat this!
CCMAIL: 39693-done@bugs.kde.org


  M +6 -0      ChangeLog   1.146
  M +44 -19    misc/loader_jpeg.cpp   1.21
  M +16 -9     rendering/render_image.cpp   1.123
  M +3 -12     rendering/render_image.h   1.48



Comment 47 Casper Planken 2004-01-10 10:41:10 UTC
Subject: Re:  loading images blocks konqueror

How does "slightly improves performance" equal "fixed"?

On Saturday 10 January 2004 09:22, you wrote:
> ------- You are receiving this mail because: -------
> You are a voter for the bug, or are watching someone who is.
>
> http://bugs.kde.org/show_bug.cgi?id=39693
> mueller@kde.org changed:
>
>            What    |Removed                     |Added
> ---------------------------------------------------------------------------
>- Status|NEW                         |RESOLVED
>          Resolution|                            |FIXED
>
>
>
> ------- Additional Comments From mueller@kde.org  2004-01-10 09:22 -------
> Subject: kdelibs/khtml
>
> CVS commit by mueller:
>
> * rendering/render_image.cpp/.h: Reduce X-server pressure with large images
> (#39693).
>
> * misc/loader_jpeg.cpp: Upon suggestion from Maksim, implement decoding of
> nonprogressive jpegs in non-buffered-image mode. This massively reduces
> memory footprint and slightly improves performance.
>
> You, you most hated Konqueror bug, eat this!
> CCMAIL: 39693-done@bugs.kde.org
>
>
>   M +6 -0      ChangeLog   1.146
>   M +44 -19    misc/loader_jpeg.cpp   1.21
>   M +16 -9     rendering/render_image.cpp   1.123
>   M +3 -12     rendering/render_image.h   1.48

Comment 48 Christian Loose 2004-01-10 12:48:08 UTC
> How does "slightly improves performance" equal "fixed"?

I'm pretty sure Dirk tested this fix with some large images.

So have you tried it?
Did you read all parts of the commit message?
Hint -> Reduce X-server pressure with large images

Comment 49 Dik Takken 2004-01-10 15:51:01 UTC
Maybe Bug 72197 has been fixed by Dirk's commit, can anyone check and maybe close it?
Comment 50 Vedran Ljubovic 2004-01-13 22:52:28 UTC
Re: comment #45 - ok, here is the new bug report: bug #72575
Comment 51 Vedran Ljubovic 2004-01-25 18:26:07 UTC
*** Bug 29420 has been marked as a duplicate of this bug. ***
Comment 52 Vedran Ljubovic 2004-01-25 19:24:24 UTC
Sorry but have to reopen this bug :(

While investigating problematic images in this bug and dupes. Most of the cases are now fixed or much better then before. Most importantly, browsing sites such as kde-look.org is now a pleasant experience. However there are still images that can seriously slow down or entirely block Konqueror. One comment says that this will be resolved in Qt 3.3 which I don't have?

Take for example this:
http://64.246.25.198/sdimages/spamdemicmap.gif
Here we have a large GIF image (900 kB) that blocks Konqueror completely. First system is blocked for a few seconds, then everything goes fine until image loading reaches a certain point, then the system is blocked and disk starts running like mad (I guess my swap is full) until I kill the process. This only happens when opening image from its original URL. When opening locally the system is frosen for a few seconds than back to normal. Mozilla works just fine with this image.

Or this link:
http://linux-wizard.tuxfamily.org/bugs/images/MarPers2.jpg
image loads perfectly fine. And here:
http://linux-wizard.tuxfamily.org/bugs/test4.html
This very same image in a HTML page will completely block my computer for a few seconds until it's fetched from cache. After that it's fine.

Also the issue described in bug #55643 (white 5000x6000 image) is not solved.
Here are the benchmarks for this image on my oldish computer:
 gqview took 3 seconds to load it - using /tmp/test.jpg 
 xview took 56 seconds to load it - using /tmp/test.jpg 
 kuickshow took 35 seconds to load it - using /tmp/test.jpg 
 kview took 71 seconds to load it - using /tmp/test.jpg
 konq took 105 seconds to load it - using /tmp/test.jpg 
 konq took 143 seconds to load it - using http://localhost/test.jpg 
 Mozilla 1.6 took 40 seconds to load it - using /tmp/test.jpg 
 Mozilla 1.6 took 40 seconds to load it - using http://localhost/test.jpg 

With other very large images (photos and such) the Konqueror window in which the photo is loading is a bit slow but other windows are unaffected, also when loading is finished Konqueror becomes very responsive. I can live with that.

This seems to be related:
http://bugs.kde.org/show_bug.cgi?id=67705
Comment 53 na77 2004-01-25 19:40:50 UTC
Also if you go to http://www.radsportnews.com: There are many small images (animated), but opening this side slows my konqueror/system down too much until I can close the window
Comment 54 Dirk Mueller 2004-01-26 05:56:26 UTC
loading of large images is as good as it can get now. you need several
additional Qt patches though. 

about the memory usage with large images: not much we can do about that, maybe Qt 4. yes, things get slow when the swap is hit, and we hit the swap faster than others with large images. 

Perhaps maksims large image loader should be used instead. 

Others: please stop adding all kinds of "slow image loading" bugs into
this bugreport, because those are all kinds of different issues which
have nothing to do with this one. 

marking as fixed.