LeifPederson;549684 Wrote:
> I'm thinking about this more and tweaking the update rate and pixel
> delta. I'm convinced, as you have already said, the payload going over
> the net is minuscule for the display updates (artist/song/album)
> compared to the stream of data that is the music itself.
That's not the data being sent ("artist/song/album"). It's being sent
a full screen image each time it's updated. I believe this is a
bitmap, although it may be compressed.
>
> I do not understand the motivation for the client/server split in the
> design for SqueezeServer.exe updating the display on the Transporter.
> Why wouldn't the design be such that the server sends the data ONCE to
> the Transporter at the beginning of each track and let the Transporter
> do the animation?
This is a really old question, probably one that I've asked as well.
I'm not a dev, but I think some of the reasons are that it's just
easier and more flexible, plus you (may) have a lot more processing
power available on the server. And you also have the availability of
using plugins that run on the server and coded in Perl by anyone.
Look at the new SqueezePlay based players. These operate more in line
with the way you're thinking. They're seriously limited by cpu and
memory constraints of the players and less flexible than the old
approach. For example, the VU meters on the Touch aren't as smooth and
there are fewer options with font sizes.
--
JJZolx
Jim
------------------------------------------------------------------------
JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10
View this thread: http://forums.slimdevices.com/showthread.php?t=77413
_______________________________________________
discuss mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/discuss
