[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Disabling loader_jpeg
From:       Dirk Mueller <mueller () kde ! org>
Date:       2003-11-02 16:55:58
[Download RAW message or body]

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! <
[prev in list] [next in list] [prev in thread] [next in thread]