Thanks Darren, excellent idea. I've added it to the list I'll post on a twiki as soon as I can find an appropriate home.
Darren Kenny wrote: > With regards to Flash - even on a single user system it can cause very heavy > loads - most web-sites use it for advertising, etc and it can really get out > of > hand. > > This is why I always use the flash block add-on - it blocks flash, but > provides > the user with a "button" which they can click if they *really* want to see the > flash (e.g. if it's core to the site), some screenshots can be seen here: > > http://flashblock.mozdev.org/screenshots.html > > I certainly think that this would be a *very* welcome addition in a Sun Ray > context. > > If needed you can also set up a "White List" of sites you would like to always > allow. > > Darren. > > Bob Doolittle wrote: > >> Brian Nitz wrote: >> >>> The intended scope is "JDS" which does include firefox and >>> staroffice. But the original optimization configuation settings for >>> JDS2 were focused on components of the base GNOME desktop. So more >>> work will need to be done. Do you have any suggestions for firefox? >>> Turn off flash animations? reduce the default cache size? >>> Configuration settings don't exist for all of these and some that do >>> exist aren't yet available to the Java Desktop Configuration Manager. >>> >> I don't think config settings exist yet which would be interesting here >> - the work has to happen in the firefox community first. My first vote >> would be for firefox to do less aggressive retention of pixmaps for >> non-visible pages (e.g. pages "Back" in the URL history several steps, >> and possibly hidden tabs). This could have a profound effect on the >> memory footprint of the X server, which is one of the biggest culprits >> in desktop resource consumption. Perhaps we could have a multi-level >> setting (e.g. 1-5) where one extreme is what we have today, maybe the >> next level is to free up pixmaps which are at least 5 steps back in >> history (I don't know where the limit is today, and am guessing its >> higher than this), and finally maybe the other extreme might be >> non-visible tabs and any history. Or maybe an idle timeout could be >> applied (but beware of chewing up CPU in order to save resources ;-). >> >> I wouldn't recommend anything heavy-handed like disabling flash >> animations unless it was simply influencing a default that the user >> could override if they chose to do so (in a fairly obvious way). We >> don't want to limit function (unless we have a very extreme >> circumstance, and I'm not convinced flash is so bad that one or two >> people can't use it now and then), we only want to reduce impact. >> >> Simple stuff could be done right off the bat. I think I still see >> staroffice doing spin loops. That's bad citizenship. Everything should >> be done off of timers or events of some sort so that the CPU can be shared. >> >> A bit OT: I'd love to see JDS pick up and refine xautolock >> http://freshmeat.net/projects/xautolock/ so that it's a good multi-user >> citizen (i.e. remove spin loops). We have many customers who would like >> to have a desktop session terminate if it's been idle for a certain >> period of time. That's about maximizing desktop resource utilization >> also, but on an aggregate server basis vs an individual desktop basis. >> >> -Bob >> >> Disclaimer: Opinions expressed in this mail are my own, >> and are not necessarily shared by my employer >> >> >>> I intend to gather Sun Ray performance enhancement requests which are >>> not yet configurable into a proposal for the "Gnome lite" project. >>> >>> Bob Doolittle wrote: >>> >>>> Hi Brian, >>>> >>>> First off - kudos for dusting off the perf doc and making it current. >>>> That'll be a big help to folks. >>>> >>>> Comment inline: >>>> >>>> Brian Nitz wrote: >>>> >>>>>>> And even better if that configuration were visible and could be >>>>>>> leveraged >>>>>>> by higher-level apps :-) >>>>>>> >>>>>> I agree. It might be helpful if we talked through how we think this >>>>>> should work. >>>>>> >>>>> Most if not all of the performance related gconf keys are now >>>>> exposed via Sun Java Desktop System Configuration manager (was >>>>> APOC). This document >>>>> (http://www.sun.com/bigadmin/content/submitted/jds_optimize.html) >>>>> was written for JDS2 linux, but the changes necessary to make these >>>>> policies work went into the codebase for JDS3 on Solaris 10. >>>>> >>>> Since "JDS" encompasses some pretty pertinent higher-level apps, >>>> as well as the desktop, I wonder what scope you're describing here? >>>> When you say "changes necessary to make these policies work" >>>> are you suggesting that firefox (for example) is now looking at >>>> these keys and changing its behavior? >>>> >>>> That's the sort of thing I was imagining with my comment, but >>>> I'd be (very pleasantly! :-) ) surprised to hear that such work has >>>> already been done. >>>> >>>> -Bob >>>> >>>> >> _______________________________________________ >> desktop-discuss mailing list >> desktop-discuss at opensolaris.org >>
