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