Re: zbitx, compiler optimizations #zbitx
¿ªÔÆÌåÓý
OK, I guess I should read that thread. I think the i2c communication must be excessive in general. ?It makes audible noise (everybody¡¯s complaining about ¡°chugging"), but I¡¯ve also found that when I have a USB ethernet adapter attached, communication there makes noise too. ?(Of course, the electrical design could be better, but I don¡¯t yet know how to pinpoint why that is happening.). (To me it sometimes sounds like hard drive seeking noises. ?;-) ?One obvious solution to do less communication is using notifications/signals: each field should notify when it has changed (only when the stored value really changed), and that should trigger the updates: those that go to the GTK UI, i2c UI update commands, and/or some network protocols. ?In Qt one uses signals: ? But I think gtk/glib has something like that too. ?? leads to?? : yep that looks like what we need. For 9p I just tried an explicit callback first (and I¡¯m not calling it from enough places yet): void notify_field_changed(const char *field_id, const char *old, const char *newval); The implementation of this function could take care of notifying the various UIs and network protocols. ?But probably it should rather emit a signal: each ¡°client¡± should subscribe for notifications. ??is something that just about everybody has to do at some point... Sbitx/zbitx is doing too much polling and timer-based refresh instead, and that is creating a lot of inefficiency. ?Especially with the excessive string comparison and conversion going on. The network protocol is important to me because I want to decouple the GUI from the radio daemon anyway. ?This daemon will eventually need to avoid using gtk/gdk at all: pure C for the core functionality. ?(Why does zbitx have to run X11 and a GTK UI under the condition that nobody is looking at it? ?Sometimes HDMI is connected, sometimes not. ?We only have 512MB, and startup time is noticeable too.) ?9p is gonna be great for that, eventually, probably. ?I have a working client on Plan 9 now, just rather buggy and incomplete compared to the GTK one. ?I just got a waterfall added to it, without taking much bandwidth (because I only send the latest line of samples at a time; too bad it¡¯s only about 440 actual pixels, despite the memory allocated to hold 1024 * history size). And later I will do a Qt client with the same protocol, for all the other platforms. ?That one can have fancier features. |