On Sunday 02 of November 2003 17:55, Dirk Mueller wrote:
> 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.

 Aren't qt-copy patches #0005,#0006 and #0007 enough? Even with them there's 
still usually the QImage -> XImage conversion (how slow it is depends on the 
color depth), if it would be really needed, I think it it shouldn't be 
difficult to either load the jpg directly to the XImage format, or do the 
QImage->XImage conversion only for the new data.

-- 
 Lubos Lunak
 l.lunak@suse.cz     l.lunak@kde.org