From kfm-devel Sun Nov 02 16:55:58 2003 From: Dirk Mueller Date: Sun, 02 Nov 2003 16:55:58 +0000 To: kfm-devel Subject: Re: Disabling loader_jpeg X-MARC-Message: https://marc.info/?l=kfm-devel&m=106779219011270 On Sunday 02 November 2003 17:24, Zack Rusin wrote: > http://bugs.kde.org/show_bug.cgi?id=39693 is full of them. Try with and > without HAVE_JPEG code paths: well, they don't block at all here. all works fine. I guess it very much depends on how inefficient your graphics card driver is. > http://www.canon.co.jp/Imaging/EOS1DS/downloads/Portrait1l.JPG perfect example of why progressive loading can not be disabled: this image takes over 30 seconds to load here. can you guess how many bugreports we'll get about that then? the problem here is that a) painting very wide stripes (like this image being > 2048px wide) is very inefficient in some x servers. b) we cause too many progressive updates, because the block size is too small and libjpeg has to resync very often. we can fix both cases. ideally we want something like imlib which provides MitShmPutImage, but for now fixing a) and b) should be a good start. Zack, don't get me wrong: I know that the code sucks, and it doesn't suck because of loader_jpeg. when you convert the .jpg to a .gif of that size and put it there, it will produce the very same problem. People blame the .jpg reader because they only browse porn or wallpaper sites and thats where you get rather large images from . We can still disable the code one week before 3.2 final. I don't want to have it disabled now when we can still work on a better solution. -- > Looking for a KDE-related EMail-Alias ? Get one at kdemail.net for FREE! <