- Visual effects are sensible and different people want different level of effects
- suggestion is to offer effects levels "none", "normal", "extra"
- effects level should influence: drop indication animation, drag ghost image animation, sliding windows rolling
effects, floating window transparency, opening/closing top components.
time estimation: 1 man week if parts to apply options for are prepared to be configured by options
Visual options refused by HIE, so putting this on hold. We will see later if user's demand will change HIE's decision.
reopening, will reassign to Jano
I don't agree with the solution "no options". The new features *can* decrease IDE performance/responsiveness. Not all
the users are interested in eye-candies. There are definitely some users that are interested in features that make they
work easier and faster not slower but with nice visual effects.
IMO, we need to provide a option for users to SWITCH OFF the new WS effects. Please, re-evaluate following proposal for
panel in Options
Window System Effects
(*) Turn On - checked by default
( ) Turn Off
I'm also increasing priority to P1 to get answer befor CF of 6.1
We had a discussion about this issue with Dafe and Standa. As a general rule I agree that if there's a full range of visual effects, it make sense to permit users
turn it off or customize. Some users may not like visual effects as they can be perceived as slow or distracting. At the same time I believe we're not there yet
(full range of visual effects), so we should rather focus on tuning them to make them work for majority of users.
Lukasi, please be specific about which visual effect don't perform well. I know we turned the effects off on some of the platforms.
The transparency and d'n'd of window (ghost window image) decreased the performance d'n'd on slower machines that we
have here. The first question/report about the new WS FX was - How to turn it off? see issue 128932. Other comments at -
>"so we should rather focus on tuning them to make them work for majority of users."
I agree with you about "tunning" issue however I don't see a connection to the this topic. Turn off/on will behave in
the same way regardless of the set of ws effects. It either turns ON ALL available(I mean implemented) effect on
particular OS or it will turn OFF ALL ws fx.
We turned off DND preview image on Solaris (see Issue 128524 ).
This ghost image window is:
1] transparent when this is supported by your OS (composite window manager on Linux, -J-Dsun.java2d.noddraw=true switch
on MS Windows)
2] non-transparent when your OS can't provide transparency (this was the case of Solaris - there is no composite wm for
Solaris 10 or older, it is also case of Linux without composite wm)
Our problem is, that performance of DND is worse compared to nb 6.0 in case 2].
Case 1] is ok, it's even faster than 6.0 was.
It would be nice to have the possibility to turn off DND preview image completely (as in case of Solaris).
One good reason is:
Composite window managers in Linux are not much stable now. They are usable, but even NetNeans has problems with them
(gray windows without any visible components). And there are many programmers who prefer stable solutions to eye-candy
ones. So many of them are using common window managers without transparency support. In this case, DND of windows is
slower in 6.1 than was on nb 6.0 - without any possibility to easily turn the thing off.
In my opinion, installing composite window manager on Linux is not the right way to speed up DND in 6.1.
One more reason:
If the eye-candy graphic effects (transparency, translucency, etc.) of the window manager are off, the dragged image is
fully opaque so the user cannot see its target position. This makes this feature counterproductive (read: it makes the
IDE less usable, less accessible).
A panel for visual effects options will be added in 6.1 as a late UI change, based on the feedback here and the feedback
from the Beta users.
implemented, panel added:
Created attachment 58853 [details]
screenshot how new options panel look. I decided to put more switches as simple on/off switch is too small for such an area
Verified in development build 080327.