Aye, there's the rub. I'm not sure if that's possible. :( You could create a progress monitor, but the progress monitor won't be called between MCUs. It is only called once for each call to jpeg_read_scanlines(), so I think the best granularity you could achieve would be for the progress monitor to be called between each MCU row. Also, since the MCU column counter is internal, there wouldn't be any way of tracking the progress in terms of individual MCUs decoded unless you made a backward-incompatible modification to the library.
I really think the best thing you can do is to use a larger buffer in order to reduce the ratio of slow to fast MCU decodes to the point that the slow MCU decodes are an insignificant part of the overall execution time. That's essentially what the TurboJPEG wrapper does. On 6/16/17 2:44 PM, Leon Scroggins via Libjpeg-turbo-devel wrote: > Thanks! Is there a good way to ensure that fill_input_buffer is called > (i.e. the buffer is empty) at the start of an MCU? Otherwise I could > imagine that we might use a large enough value, but still end up hitting > the slow case because we exhaust our buffer in the middle of the first MCU. > > On Fri, Jun 16, 2017 at 3:17 PM, DRC via Libjpeg-turbo-devel > <libjpeg-turbo-devel@lists.sourceforge.net > <mailto:libjpeg-turbo-devel@lists.sourceforge.net>> wrote: > > Referring to the code in jdhuff.c, the slow case will be used if: > (1) There are fewer than cinfo->blocks_in_MCU * 128 bytes in the > buffer, or > (2) There is an unread marker from a previous entropy decode (such as a > restart marker), or > (3) The fast case encounters a marker (such as a restart marker) > > There is nothing you can do about (2) and (3), but you should be able to > minimize the use of the slow path by ensuring that at least > cinfo->blocks_in_MCU * 128 bytes are in the buffer. You may not be able > to ensure that at the end of the image, though. > > On 6/16/17 11:29 AM, Leon Scroggins via Libjpeg-turbo-devel wrote: > > What is the best way to determine how much data to pass to > > fill_input_buffer? Often we are streaming data, so we need to copy it > > into a buffer before providing it. We've noticed that depending on the > > amount of data in the buffer, libjpeg-turbo will call either call > > decode_mcu_slow or decode_mcu_fast, which can make a difference in > > decoding speed. We can always use a large buffer in order to make us > > more likely to hit the fast case, but we can still hit the slow case > > sometimes. I was wondering if there might be some query we can use to > > determine the ideal amount of data to supply in a given call to > > fill_input_buffer so that we never hit the slow case? > > > > -- > > > > • Leon Scroggins > > > > • scro...@google.com <mailto:scro...@google.com> > <mailto:scro...@google.com <mailto:scro...@google.com>> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Libjpeg-turbo-devel mailing list > Libjpeg-turbo-devel@lists.sourceforge.net > <mailto:Libjpeg-turbo-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-devel > <https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-devel> > > > > > -- > > • Leon Scroggins > > • scro...@google.com <mailto:scro...@google.com> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Libjpeg-turbo-devel mailing list Libjpeg-turbo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-devel
