[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: Progress bar animations for KDE 4.4/4.5 ?
From:       Thomas =?iso-8859-1?q?L=FCbking?= <thomas.luebking () web ! de>
Date:       2010-01-31 15:48:51
Message-ID: 201001311648.51288.thomas.luebking () web ! de
[Download RAW message or body]

This is probably the wrong group (meant kde-core-devel?)

However:
---
Probably wrong approach.
As the smooth animation is a pure visual thing (do NOT change the value or 
min/maxvalues - this will sooner or later lead to segfaults in the usercode - 
esp. if you've got a 1 second animation) it needs to be handled in the 
painting code, i.e either by manipulating the QStyleOption in 
KProgressBar::paintEvent() or directly in the style (i.e. animate there)

Also be aware that a 5ms timer is probably overhead (this is 200fps - far 
beyond human abilities, 20ms makes 50fps and is by far enough, 33ms should be 
good and 40ms are sufficient) and also will not work on all systems (i think 
Qt on windows up to XP xould only provide 20ms timer intervals)

Cheers

Am Sunday 31 January 2010 schrieb Vishal Rao:
> Hi,
> 
> I was pointed towards Hugo Pereira Da Costa by Aaron (aseigo) on IRC about
>  my questions regarding KDE 4.4's progress bar animation which is
> currently quite bare.
> 
> Thanks to you Hugo for showing me around the code. Here is a youtube clip
>  of my work for today: http://www.youtube.com/watch?v=zrvCprVHqag   :-)
> 
> Unfortunately, the code for the demo video has severe caveats/cheats
> and in spite of my
> bare knowledge of Qt/KDE code it looks like KDE will need a
>  wrapper/decorator class "KProgressBar" or send patches to Qt to extend
>  QProgressBar for really sweet animations.
> 
> I've changed KDE 4.4 progressbar anim code (oxygen files) to:
> 
> * Use InOutQuint instead of InOutQuad QtEasingCurve for more pronounced
> movement (more amplitude I think)
> * Increased the "duration" parameter from 200 (default 250) to 1000 ms.
> * Set timer interval down from 50ms to 5ms.
> * Changed so-called "opacity" min/max from 0.1/0.9 to full 0.0/1.0 range.
> * Tweaked the valueChanged() and timerEvent() callbacks/slots.
> 
> The "severe caveats" I was mentioning, are, if I'm not mistaken:
> 
> * QProgressBar setValue/valueChanged are being conflictingly used by
> user code as well as the animation engine - a QtProgressBar limitation at
> the moment I believe.
> * User must create progressbar with large number of steps (100 or in the
>  video's case 1000) to get smooth effect. If you create for example a
>  progressbar with just 3 steps it will jump sharply from one to another
>  with no
> animation possible.
> 
> Thats why I believe a "KProgressBar" will be necessary to differentiate
>  between user-set values/steps and internal animation based higher
>  granularity steps.
> 
> Hugo also advised me that maybe I should look at scrollbar pageup/pagedown
> animation to make it smooth too, and I am happy and motivated to try my
> hand at that :-)
> 
> I was hoping it would be a minor fix so that perhaps KDE 4.4.1 might
> have this in
> time for my distro (Kubuntu's) LTS release, but sadly looks like something
>  that can only happen for the 4.5 timeframe at the earliest.
> 
> Regards,
> Vishal
> 

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]