multiple-scan images consume a lot of CPU
Hi, I really like the multiple-scan image feature added to dillo recently, but it uses quite some CPU and makes it drag slow when going back and forth on pages with a lot of images. So as the "TODO" comment in jpeg.c already suggests, we need some way to switch off multiple-scan when the image is readily available either from cache, from disk, or from a fast network connection. I think some sort of rate limiting would be best that restricts rescans to - say - once a second. What do you think? Cheers, Johannes
Johannes wrote:
I really like the multiple-scan image feature added to dillo recently, but it uses quite some CPU and makes it drag slow when going back and forth on pages with a lot of images.
So as the "TODO" comment in jpeg.c already suggests, we need some way to switch off multiple-scan when the image is readily available either from cache, from disk, or from a fast network connection.
I think some sort of rate limiting would be best that restricts rescans to - say - once a second.
What do you think?
Just as a quick experiment, would something like the following do much good? diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c --- dillo2/src/jpeg.c 2008-01-16 02:57:32.000000000 +0000 +++ dillo2-cur/src/jpeg.c 2008-03-15 22:10:59.000000000 +0000 @@ -293,7 +293,7 @@ static void Jpeg_write(DilloJpeg *jpeg, * when an image arrives slowly, but should not be used to redisplay * cached images. */ - if (jpeg_has_multiple_scans(&jpeg->cinfo)) + if ((BufSize < 2000) && jpeg_has_multiple_scans(&jpeg->cinfo)) jpeg->cinfo.buffered_image = TRUE; a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image,
On Sat, Mar 15, 2008 at 10:16:09PM +0000, place wrote:
Johannes wrote:
I really like the multiple-scan image feature added to dillo recently, but it uses quite some CPU and makes it drag slow when going back and forth on pages with a lot of images.
So as the "TODO" comment in jpeg.c already suggests, we need some way to switch off multiple-scan when the image is readily available either from cache, from disk, or from a fast network connection.
I think some sort of rate limiting would be best that restricts rescans to - say - once a second.
What do you think?
Just as a quick experiment, would something like the following do much good?
diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c --- dillo2/src/jpeg.c 2008-01-16 02:57:32.000000000 +0000 +++ dillo2-cur/src/jpeg.c 2008-03-15 22:10:59.000000000 +0000 @@ -293,7 +293,7 @@ static void Jpeg_write(DilloJpeg *jpeg, * when an image arrives slowly, but should not be used to redisplay * cached images. */ - if (jpeg_has_multiple_scans(&jpeg->cinfo)) + if ((BufSize < 2000) && jpeg_has_multiple_scans(&jpeg->cinfo)) jpeg->cinfo.buffered_image = TRUE;
a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image,
That does not quite work for smaller images. The threshhold would need to depend somehow on the total size of the image. And I get "Improper call to JPEG library in state 205" but that should be easily avoidable. Cheers, Johannes
Johannes wrote:
On Sat, Mar 15, 2008 at 10:16:09PM +0000, place wrote:
Johannes wrote:
So as the "TODO" comment in jpeg.c already suggests, we need some way to switch off multiple-scan when the image is readily available either from cache, from disk, or from a fast network connection.
I think some sort of rate limiting would be best that restricts rescans to - say - once a second.
That does not quite work for smaller images. The threshhold would need to depend somehow on the total size of the image.
Do you encounter them much? I was hoping it was too rare to care about. Looking at the bottom of Cache_process_queue(), maybe clients could be taught to understand CA_Close in place of the last CA_Send for an entry. Or some interface to get our hands on the cache entry's CA_GotData flag. I don't know; Jorge will know better.
And I get "Improper call to JPEG library in state 205" but that should be easily avoidable.
Sorry, I was in a bit of a hurry at the time, and I don't have any multiple scan jpegs now to try it on (could you point me to some?) It should have been something more like diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c --- dillo2/src/jpeg.c 2008-01-16 02:57:32.000000000 +0000 +++ dillo2-cur/src/jpeg.c 2008-03-15 23:24:21.000000000 +0000 @@ -293,7 +293,7 @@ static void Jpeg_write(DilloJpeg *jpeg, * when an image arrives slowly, but should not be used to redisplay * cached images. */ - if (jpeg_has_multiple_scans(&jpeg->cinfo)) + if ((BufSize < 2000) && jpeg_has_multiple_scans(&jpeg->cinfo)) jpeg->cinfo.buffered_image = TRUE; a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image, @@ -309,7 +309,7 @@ static void Jpeg_write(DilloJpeg *jpeg, /* decompression step 5 (see libjpeg.doc) */ if (jpeg_start_decompress(&(jpeg->cinfo))) { jpeg->y = 0; - jpeg->state = jpeg_has_multiple_scans(&jpeg->cinfo) ? + jpeg->state = jpeg->cinfo.buffered_image ? DILLO_JPEG_READ_BEGIN_SCAN : DILLO_JPEG_READ_IN_SCAN; } } @@ -355,7 +355,7 @@ static void Jpeg_write(DilloJpeg *jpeg, if (jpeg->y == jpeg->cinfo.image_height) { /* end of scan */ - if (!jpeg_has_multiple_scans(&jpeg->cinfo)) { + if (!jpeg->cinfo.buffered_image) { jpeg->state = DILLO_JPEG_DONE; break; } else {
On Sat, Mar 15, 2008 at 11:46:59PM +0000, place wrote:
Johannes wrote:
On Sat, Mar 15, 2008 at 10:16:09PM +0000, place wrote:
Johannes wrote:
So as the "TODO" comment in jpeg.c already suggests, we need some way to switch off multiple-scan when the image is readily available either from cache, from disk, or from a fast network connection.
I think some sort of rate limiting would be best that restricts rescans to - say - once a second.
That does not quite work for smaller images. The threshhold would need to depend somehow on the total size of the image.
Do you encounter them much? I was hoping it was too rare to care about.
Forget about this comment for now. Your patch below works great for me. I was seeing the problem for example on http://www.tourentipp.de When I went back to that page, it was pretty slow. Thanks, Johannes
Looking at the bottom of Cache_process_queue(), maybe clients could be taught to understand CA_Close in place of the last CA_Send for an entry. Or some interface to get our hands on the cache entry's CA_GotData flag. I don't know; Jorge will know better.
And I get "Improper call to JPEG library in state 205" but that should be easily avoidable.
Sorry, I was in a bit of a hurry at the time, and I don't have any multiple scan jpegs now to try it on (could you point me to some?)
It should have been something more like
diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c --- dillo2/src/jpeg.c 2008-01-16 02:57:32.000000000 +0000 +++ dillo2-cur/src/jpeg.c 2008-03-15 23:24:21.000000000 +0000 @@ -293,7 +293,7 @@ static void Jpeg_write(DilloJpeg *jpeg, * when an image arrives slowly, but should not be used to redisplay * cached images. */ - if (jpeg_has_multiple_scans(&jpeg->cinfo)) + if ((BufSize < 2000) && jpeg_has_multiple_scans(&jpeg->cinfo)) jpeg->cinfo.buffered_image = TRUE;
a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image, @@ -309,7 +309,7 @@ static void Jpeg_write(DilloJpeg *jpeg, /* decompression step 5 (see libjpeg.doc) */ if (jpeg_start_decompress(&(jpeg->cinfo))) { jpeg->y = 0; - jpeg->state = jpeg_has_multiple_scans(&jpeg->cinfo) ? + jpeg->state = jpeg->cinfo.buffered_image ? DILLO_JPEG_READ_BEGIN_SCAN : DILLO_JPEG_READ_IN_SCAN; } } @@ -355,7 +355,7 @@ static void Jpeg_write(DilloJpeg *jpeg,
if (jpeg->y == jpeg->cinfo.image_height) { /* end of scan */ - if (!jpeg_has_multiple_scans(&jpeg->cinfo)) { + if (!jpeg->cinfo.buffered_image) { jpeg->state = DILLO_JPEG_DONE; break; } else {
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Your patch below works great for me.
:) Here's a proper patch with proper comments. PS If anybody happens to have deep knowledge of various sorts of networking, maybe they'll know an optimal value for a BufSize test. All I know is that modem mtu is 15xx.
On Sun, Mar 16, 2008 at 04:41:08PM +0000, place wrote:
Your patch below works great for me.
:)
Here's a proper patch with proper comments.
PS If anybody happens to have deep knowledge of various sorts of networking, maybe they'll know an optimal value for a BufSize test. All I know is that modem mtu is 15xx.
Committed. I'd prefer to be sure that cached images always render in one pass, but this workaround is simple and good enough to commit, until someone comes with a better idea. -- Cheers Jorge.-
Jorge wrote:
I'd prefer to be sure that cached images always render in one pass, but this workaround is simple and good enough to commit, until someone comes with a better idea.
Well, there was some discussion not too long ago on the list about a capi interface to get the status of cache entries... :)
participants (3)
-
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
place＠gobigwest.com