Fix performance regressions #119
Conversation
Needed for some tests.
The only class that cares if connections are reversed or not is VNCSConnectionST so let it keep track of this fact.
It had regressed in performance compared to 1.3. This brings it back up to the same speed.
It knows more details so it can track things better.
The previous FIXME was incorrect. The old code did in fact continue looking over the entire area. This commit restores that old behaviour.
|
encperf: For the 24-bit datasets, encperf generates similar results to my hacked-up compare-encodings benchmark, but on the 16-bit and 8-bit datasets, the raw equivalent byte count appears to be off (I'll generate a new issue for that.) I've generated PR #124 to add the display of the encoded byte count and raw-equivalent byte count to encperf's output (I need this data, because I often want to compute compression ratios for groups of datasets.) decperf: Everything LGTM. Performance numbers match the decoding numbers from my custom benchmark code. |
|
Actually, I now see what the issue is with the raw-equivalent bytes. The computation of them is using the client-side pixel format instead of the server-side pixel format, and the client-side pixel format in encperf is always 32-bit. compare-encodings behaves differently. It will use the same pixel format for client and server unless you are generating a session capture, in which case it will always convert to 24-bit. I would propose that encperf behave similarly, or at least that an option be added to it so that it can use the same server & client pixel format, even if that behavior isn't the default. |
Fix some performance regressions that were introduced when we cleaned up the codecs. Fixes #63.