Avoid re-calculating the xScaleBlockOffset when not necessary in JpegImage._getLinearizedBlockData
#11557
Conversation
…pegImage._getLinearizedBlockData` As can be seen in the code, the `xScaleBlockOffset` typed array doesn't depend on the actual image data but only on the width and x-scale. The width is obviously consistent for an image, and it turns out that in practice the `componentScaleX` is quite often identical between two (or more) adjacent image components. All-in-all it's thus not necessary to *unconditionally* re-compute the `xScaleBlockOffset` when getting the JPEG image data. While avoiding, in many cases, one or more loops can never be a bad thing these changes are unfortunately completely dominated by the rest of the JpegImage code and consequently doesn't really show up in benchmark results. *Hence I'd understand if this patch is ultimately deemed not necessary.*
|
/botio test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/ab28006e3eeff70/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/ae4fa1700398e8d/output.txt |
From: Bot.io (Windows)FailedFull output at http://54.215.176.217:8877/ae4fa1700398e8d/output.txt Total script time: 2.21 mins
Image differences available at: http://54.215.176.217:8877/ae4fa1700398e8d/reftest-analyzer.html#web=eq.log |
From: Bot.io (Linux m4)FailedFull output at http://54.67.70.0:8877/ab28006e3eeff70/output.txt Total script time: 19.46 mins
Image differences available at: http://54.67.70.0:8877/ab28006e3eeff70/reftest-analyzer.html#web=eq.log |
|
This, and the other recent patches for |
|
/botio-windows test |
From: Bot.io (Windows)ReceivedCommand cmd_test from @timvandermeij received. Current queue size: 0 Live output at: http://54.215.176.217:8877/78f7c83a5413be2/output.txt |
From: Bot.io (Windows)FailedFull output at http://54.215.176.217:8877/78f7c83a5413be2/output.txt Total script time: 26.23 mins
Image differences available at: http://54.215.176.217:8877/78f7c83a5413be2/reftest-analyzer.html#web=eq.log |
|
Let's do this. Thanks! |
As can be seen in the code, the
xScaleBlockOffsettyped array doesn't depend on the actual image data but only on the width and x-scale. The width is obviously consistent for an image, and it turns out that in practice thecomponentScaleXis quite often identical between two (or more) adjacent image components.All-in-all it's thus not necessary to unconditionally re-compute the
xScaleBlockOffsetwhen getting the JPEG image data.While avoiding, in many cases, one or more loops can never be a bad thing these changes are unfortunately completely dominated by the rest of the JpegImage code and consequently doesn't really show up in benchmark results. Hence I'd understand if this patch is ultimately deemed not necessary.