Won't be able to put that kind of load on the clients? In general things like this are probably better to put load on the clients than on the server if you can. Remember, the less load you put on the server the more it will scale. :)
If you really don't want to do the processing on the client sides, then here's what I would do. First, have the servers render the images and then send the full images to the clients (compressed if you can - if your images follow some well defined pattern then you might be able to come up with your own compression that will work pretty well). See how the performance is. If that performance is good enough and the bandwidth usage isn't too high then go with that for an initial pass. That's your first iteration. Once you have that working, start looking at ways to improve it. This may mean moving the rendering to the client (if you structure your code well enough this shouldn't be too big a change) or finding ways to better 'compress' the images (like using diffs). Doing something iterative like this will get you something working a lot faster, and having a fully functioning app will make it easier to tell what parts need to be optimized. Otherwise you might spend a month working on optimizing the image transport only to find out you didn't need it. -Andy On 12/1/06, Wojtek Dabrowski <[EMAIL PROTECTED]> wrote:
Hi Andy! The problem is, I really need to be operating more or less in real-time. What's happening on the server is that I'm generating a lot of single image files. Pre-rendering would be an option if I could find some program that can take a continuous supply of image files, encode them to some movie format, and stream the movie to the client. Unfortunately, I haven't been able to find something like that yet - and to make things worse, it would need to be open-source. I really can't leave rendering to the client, because in the (far) future the rendering will become so resource-intensive that I won't be able to put that kind of load on the clients. Any pointers towards a program that could do this kind of live streaming from a series of images? Thanks a lot in advance, -Wojtek On Fri, 2006-12-01 at 15:48 -0500, Andy Herrman wrote: > You're probably better off sending the commands themselves. Your > rendering algorithm may be complicated, but sending commands is almost > always going to be more efficient (and as such will probably save you > on bandwidth). > > Calculating image diffs is kind of expensive, and can be pretty > complex if you're trying to optimize it. It would probably be easier > to implement the handling of the commands, since you already know how > that has to work, than to try and do image diffs (part of the > application I work on has something that sounds a bit similar, and > we've always wanted to add image diffs, but haven't gotten to it as we > could never come up with a good enough algorithm for it). > > If that doesn't work I'd go with pre-rendering. It would use more > bandwidth and processing (on the server at least) but would be a lot > faster implementation wise than trying to implement your own image > diff generation and rendering. > > -Andy _______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
_______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
