31 Jul
2004
31 Jul
'04
9:22 a.m.
Comparatively, Meterbridge is responsible for blowing
_loads_ of CPU
cycles (as reported by Qjackctl) - Alsaplayer/Ardour graphics aren't
loading the remote box to anything like the same extent.
I'll try to make some comparative CPU measurements whilst recording and
report back, but it looks to me as though Meterbridge (probably via a
library) isn't making as efficient use of X as it might.
It's very possible that Meterbridge's "waste" isn't in the X calls,
but the
way in which it collects information and/or performs I/O in general. Years
ago when I first started to dabble in open source code and came upon a
fairly popular IRC client called "BitchX". The author of that client
decided in his infinite wisdom to basically cpu-spin on non-blocking I/Os
for "petty" network transfers, thereby wasting about 85+% CPU to oversee a
single client-to-client transfer that was probably running at 2-4
kilobytes/second, tops. It was insanely bad code.
Many people writing software against UNIX APIs often don't understand them
and the frameworks which went into their design.
If you can, try to profile where Meterbridge is wasting all of its time.
"Overupdating" the screen is another classic problem of "naive"
implementations. Doing more than 60 updates/second is really wasted as the
monitor isn't going to really display (much) more than that. Yes, the
"overhead" of maintaining update-to-update throttles is insignificant
compared to blasting thousands of bits faster than can be displayed.
In my humble opinion, the human eye isn't going to really notice faster than
20-30 updates/second, and I don't think more than that is at all useful.
An exception perhaps is if you use "inertial" object motion whereby you
maintain precise Xvelocity and Yvelocity, updating it at the maximum refresh
rate is a win for smoothness as the inter-frame object displacement can be
smaller which is much more pleasing.
=MB=
--
A focus on Quality.