The original Glitch64 LOG macro was used only for development/debugging
purposes and was never intended to be used in any sort of end-user
context. It is invoked in every gr* method, which produces dozens of
log entries per frame.
The commit referenced above changed the LOG macro to use m64p verbose
logging, which is presentable to the user. There are two problems with
that:
With verbose logging enabled, the Glitch64 messages completely swamp
the verbose messages from all other modules as well as Glide64 and
GlideHQ. Not only does this make it difficult to parse information
from the logs, but it also brings framerate to an unusable 1-3 FPS on
a modern PC.
Even with verbose logging disabled, the overhead alone of assembling
log messages (even if never displayed) is enough to significantly
reduce frame rate. This is especially noticeable on mobile hardware.
For example, on a Tegra3-based 2012 Nexus 7, framerate during the
DK64 intro rap scene is very noticeably slower with LOG enabled:
with LOG enabled: 7-20 FPS
with LOG disabled: 15-30 FPS
In many places, FPS doubles after disabling the LOG macro.
Reverts change made in commit b037632. https://github.com/mupen64plus/mupen64plus-video-glide64mk2/commit/b0376322c9be55b3348c28eb13c8d2b375161ddb#diff-ae724f0d8acdb55b9336c5905ba15311R280
The original Glitch64 LOG macro was used only for development/debugging purposes and was never intended to be used in any sort of end-user context. It is invoked in every gr* method, which produces dozens of log entries per frame.
The commit referenced above changed the LOG macro to use m64p verbose logging, which is presentable to the user. There are two problems with that: