To me, this sounds a bit too comprehensive for Pivot 1.x. It would touch a lot of code that currently works very well, and I'm not sure that there is a strong enough use case to justify the risk of introducing bugs into that code. Is poor graphics hardware really a concern for our target users? Even if it is, have we actually verified that Pivot runs poorly on such hardware?
The question in my mind is - why might we want to invest time in this, as opposed to some of the other issues we have on our to-do list? Personally, I see a lot of other features on the road map that would offer a lot more value to me than this. I could see potentially considering something like this for Pivot 2.0, when we start building out the new theme classes, but it seems like a very low priority item right now. Honestly, I don't think we should consider taking any action on this item until we learn more about how our users are using Pivot, and what their pain points are. If this isn't one of them, we definitely shouldn't spend any time on it. If it is, then we can discuss whether this is the right solution or if another approach would be better (maybe for Pivot 2.0, when we start working on the new theme classes). G On Thursday, October 01, 2009, at 10:12AM, "Sandro Martini" <[email protected]> wrote: >Ok, I'll try to explain the idea in short terms (some point is already >explained in the JIRA ticket): > >The default behavior will be full effects ON, like currently. > >This proposal is to disable groups of effects by switching them OFF, >depending on what is (not) wanted. >We have to see if providing an enum with some common levels (like ALL, >MEDIUM, LOW, NONE) but in this case we have to see in what category an >effect is ... but this is a detail. > >The main use case for this is to exclude unwanted graphics effects, to >speedup execution of Pivot Applications / Applets, think for example >at Corporate (Intranet) Applications where usually the Graphics aspect >if less relevant, and usually there are many PCs (old, or at least >some year old) with not-so-good Graphics Boards ... like many Intel >boards, or with poor drivers. >GNome desktop has a feature like this, in the Graphic Configuration, >but this is based on the Graphics Board hardware functions ... > >So, if i could let developers customize (by code and/or in wtkx files) >what effects exclude (and maybe disable and re-enable later) to >speedup all. > >With "effects" here I'm thinking on: >- media >- transitions >- transparencies >- gradients >- backgrounds >- watermarks >- drawings >- maybe others ... like background colors, custom styles, etc ... > > >So a refactoring of some parts of graphics generation code should be >done (and this could be useful, in any case) in common methods, and >see if make if statements there to see if not process the code to >draw, ok ? > >As a first example, I'd like to try with the gradients part ... >probably on modern PC with good Graphics Boards the speedup is >minimal, but i think this is another useful feature to have. > >Or for example think on transitions: if i don't want them, i could >disable all them (skipping the related code in new common methods, >depending on the related flag), so users doesn't have to wait for >transitions to complete (also if is can set their duration as little >as possible, ok). > > >Comments ? > >Bye, >Sandro > >
