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
