|
2011-09-28
, 06:50
|
Posts: 875 |
Thanked: 918 times |
Joined on Sep 2010
|
#102
|
The main question is the list scrolling performance. I can't say that I utilize all possible optimizations.
The other interesting thing is in-window UI rotation with rightmost toolbar button. Please notice that scrolling performance decreases noticeably when UI is rotated.
The Following User Says Thank You to auouymous For This Useful Post: | ||
|
2011-09-28
, 07:14
|
Posts: 86 |
Thanked: 29 times |
Joined on Sep 2011
|
#103
|
|
2011-09-28
, 07:18
|
Posts: 355 |
Thanked: 598 times |
Joined on Sep 2009
@ Nizhny Novgorod, Russia
|
#104
|
|
2011-09-28
, 07:19
|
Posts: 2,802 |
Thanked: 4,491 times |
Joined on Nov 2007
|
#105
|
|
2011-09-28
, 07:34
|
Posts: 875 |
Thanked: 918 times |
Joined on Sep 2010
|
#106
|
But if we don't want to rotate buffer every time, the buffer will need to contain widgets in rotated form and all widget drawing operations need to be rotated individually while painting into the buffer. I think this might be slower...
|
2011-09-28
, 07:35
|
Posts: 355 |
Thanked: 598 times |
Joined on Sep 2009
@ Nizhny Novgorod, Russia
|
#107
|
The Following User Says Thank You to Mitrandir For This Useful Post: | ||
|
2011-09-28
, 07:43
|
Posts: 355 |
Thanked: 598 times |
Joined on Sep 2009
@ Nizhny Novgorod, Russia
|
#108
|
If we want scrolling to be faster or smoother, it seems that we will need to drop transparency effects
|
2011-09-28
, 07:46
|
Posts: 875 |
Thanked: 918 times |
Joined on Sep 2010
|
#109
|
Every user will have his two favorite orientations and the button should toggle between them. Which two to use might be customized in settings.
I think forward/backward buttons should switch tracks on short tap and do fast forward/reverse on long tap.
lma, yes, seekbar's hot area now has the same height as round glowing and overlaps bottom part of the list and upper part of the toolbar. I'm not sure how to solve this. May be make non-rectangular hot area — wide around current position indicator and narrow elsewhere.
|
2011-09-28
, 07:49
|
Posts: 875 |
Thanked: 918 times |
Joined on Sep 2010
|
#110
|
If we will blit already rendered window contents, this will 'scroll' transparent elements too. But if we introduce the limitation that no transparent elements can be drawn over scrolling areas, then yes, it is possibly can be improved as you described.
In the current Kroll's design this will affect round corners around the playlist and seekbar's glowing.
I have uploaded ‘simp-test’ package into Extras-Devel.
It will not create any menu items (yet), so after installation please open X-Terminal and run ‘lxtest’ command.
This is just a simple UI demo for now with player buttons, seekbar and scrollable list (no kinetic scrolling yet).
The main question is the list scrolling performance. I can't say that I utilize all possible optimizations. But approach that I have implemented is pretty flexible and allows semi-transparent UI elements to be drawn above each other. If we want scrolling to be faster or smoother, it seems that we will need to drop transparency effects (but I'm not sure that it will make it faster significantly).
The other interesting thing is in-window UI rotation with rightmost toolbar button. Please notice that scrolling performance decreases noticeably when UI is rotated. That's simply because I need to rotate offscreen buffer before blitting it to the window.
Actually, I don't see any way to increase performance of rotated UI. For basic drawing operations (rectangles, lines) rotation can be done quickly with just coordinates transformation. But not for texts. Any ideas are welcomed.
But as you can notice this demo starts up pretty fast
So, what do you think about this demo and its performance?
Current source can be cloned from BitBucket: https://bitbucket.org/IlyaSkriblovsky/simp
Source of this package: http://repository.maemo.org/extras-d...source/s/simp/
Package for desktop linux: http://repository.maemo.org/extras-d...t_0.1_i386.deb
Last edited by Mitrandir; 2011-09-28 at 06:04.