On Sunday 02 November 2003 11:55, Dirk Mueller wrote:
> a) painting very wide stripes (like this image being > 2048px wide)
> is very inefficient in some x servers.

yap.

> b) we cause too many progressive updates, because the block size is
> too small and libjpeg has to resync very often.

yap. I have tested different block sizes. The bottleneck on my system 
was that the source was often waiting for the sink but it'd be probably 
a whole different story on a low-bandwidth connection. 

> 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.

Well, I just checked out Mozilla libpr0n. I tested the same pictures on 
Mozilla and I was more then impressed, their progressive loading is 
really well done.

> 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 .

Trust me there's a difference. I converted some of the presented images 
to the gif format (of course we all know that converting jpeg to gif is 
a bad idea, but anyway) - there really is a big difference between 
loading progressively a jpeg and normally the gif. Anyway, I'll do some 
profiling and see what we can do.

Zack

-- 
As long as there are tests, there will be prayer in public schools.