Reply
Thread Tools
Posts: 875 | Thanked: 918 times | Joined on Sep 2010
#141
Originally Posted by Mitrandir View Post
Spent two days (evenings) implementing per-op rotation. Result: it doesn't give any performance advantage. I'm not sure why: whether my code is very dirty and unoptimized, doing tens of matrix multiplications per frame or there some other reason.
But that's it.
Do you render text one character at a time or full line? You could special case each orientation (no on-the-fly transformations) in each widget and pre-rotate textures.

I think the rotation buffer would be faster and have cleaner code than individual widget transformation, unless you special case them. In normal orientation the buffer isn't rotated and would be faster than widget code that can do transformations, even if special cased, right?
 

The Following 2 Users Say Thank You to auouymous For This Useful Post:
Posts: 355 | Thanked: 598 times | Joined on Sep 2009 @ Nizhny Novgorod, Russia
#142
Do you render text one character at a time or full line?
Whole line of course

You could special case each orientation (no on-the-fly transformations) in each widget and pre-rotate textures
I started to special case all drawing operations, but soon I've noticed that I hate my code more and more So, I threw it away, wrote general Matrix class to work with transformation matrix, and started to recall linear algebra course (with squeak and rasp). After all I wrote general affine transform support for my Canvas class which does matrix×point multiplications for each drawing op Of course this is slower than a lot of switch'es, but I believe that these number multiplications is still lot faster than actual drawing. So I don't think that special-casing will increase performance dramatically, though it should be somewhat faster of course (or may be I just hate special-casing ).

In normal orientation the buffer isn't rotated and would be faster than widget code that can do transformations, even if special cased, right?
Of course, in normal orientation the solution with rotating buffer will be faster because no rotation is actually performed and no coordinates calculation like in per-primitive rotation. As usual: dumbest solution is the best for a simple case.

(BTW, per-primitive rotation involves pixmap rotation as well, because player's buttons, header, seekbar — all consist from pixmap which need to be rotated. But speed of rotation is inversely proportional to pixmap area, so it would be relatively fast).
 

The Following 2 Users Say Thank You to Mitrandir For This Useful Post:
Posts: 875 | Thanked: 918 times | Joined on Sep 2010
#143
Originally Posted by Mitrandir View Post
(BTW, per-primitive rotation involves pixmap rotation as well, because player's buttons, header, seekbar — all consist from pixmap which need to be rotated. But speed of rotation is inversely proportional to pixmap area, so it would be relatively fast).
Are you pre-rotating those images or rotating each time your draw them?
 
Posts: 355 | Thanked: 598 times | Joined on Sep 2009 @ Nizhny Novgorod, Russia
#144
You're right, I'm rotating them every time because I was trying to make code universal...
 
Posts: 637 | Thanked: 445 times | Joined on Dec 2009 @ Kaliningrad, Russia
#145
Sad, very sad we can't use blure...

Not perfect, just a mock up.

As you can see I've modified close button a bit

Last edited by Kroll; 2011-10-06 at 18:40.
 

The Following 3 Users Say Thank You to Kroll For This Useful Post:
Posts: 875 | Thanked: 918 times | Joined on Sep 2010
#146
Originally Posted by Kroll View Post
Sad, very sad we can't use blure... As you can see I've modified close button a bit
It is too hard to read the playlist over a dimmed song list. I don't think blur or any other effect should be used when showing settings and playlists, the song list should be entirely replaced. And the active playlist should be highlighted blue or gray like the current song and there should only be a single delete button in the bottom controls along with the new playlist button and edit playlist button. This would free up the entire line for just the playlist for quick selections and keep all the less used management controls out of the way at the bottom of the screen. A horizontal swipe on the playlist should invoke the edit action but the edit button is down at the bottom for those who don't know about the swipe.

If you'd rather use an icon to mark the current playlist then use something other than the slider knob. I just think the slider knob, or any other icon, looks like a button that should do something when tapped and highlighting the background makes more sense.

And the new close button is much nicer and doesn't draw my eye away from the rest of the UI.

Edit: And UI elements should remain the same size. Meaning the playlist elements should be the same size as the song elements. If you look at the new screenshot the playlist elements have more vertical space than the song elements under them. This should be the case even if you can't see the song elements below the settings and playlists. The UI doesn't flow properly if they change sizes without a good reason.

Last edited by auouymous; 2011-10-07 at 01:04.
 

The Following 2 Users Say Thank You to auouymous For This Useful Post:
Posts: 637 | Thanked: 445 times | Joined on Dec 2009 @ Kaliningrad, Russia
#147
@auouymous
Thanks. I will make a new mockup.
Sorry, I haven't got so much time to make a new thing every day
 
Posts: 637 | Thanked: 445 times | Joined on Dec 2009 @ Kaliningrad, Russia
#148


Tap on playlist to focus on it. Use buttons in the bottom to edit or delete.
Double tap to play playlist.

Melody icon: currently playing.
Transparent background: focus.
Tap on back button in right top corner to return to song list.

upd:
Edit menu will open the similar to mockup window with Playlist name instead of title "Playlists" (tap on it to rename) and songs instead of playlist #1, RHCP, etc.
Buttons: add (submenu: folder, folder with subfolders, single file), delete (long tap to delete song from harddrive)

Last edited by Kroll; 2011-10-08 at 19:41.
 

The Following User Says Thank You to Kroll For This Useful Post:
tso's Avatar
Posts: 4,783 | Thanked: 1,253 times | Joined on Aug 2007 @ norway
#149
not sure i am a fan of "delete from harddrive", i would prefer using the file manager for that. At the very least, provide some kind of confirmation option.
__________________
Be warned, posts are often line of thoughts at highway speeds...

Last edited by tso; 2011-10-08 at 22:59.
 

The Following User Says Thank You to tso For This Useful Post:
Posts: 637 | Thanked: 445 times | Joined on Dec 2009 @ Kaliningrad, Russia
#150
not sure i am a fan of "delete from harddrive"
I am a very very big "fan" of this actually
Yes, of course confirmation must be required.
 

The Following User Says Thank You to Kroll For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 10:50.