News:

Current Full E-Touch Version: 10.2.0
Current Demo E-Touch Version: 10.0.0
Current Beta: 10.2.1 Beta 22 (09/02/23)

Main Menu

Animation / Swipe headaches and things to try.

Started by RandyT, December 10, 2013, 06:04:08 PM

Previous topic - Next topic

RandyT


After moving my skin to the target machine, I noticed that the swipe was agonizingly slow, taking about 30sec. to complete one transition.  After seeing how this was reported to be "hit and miss" with users, I thought I would share some things which improved things dramatically on my machine (Win7 x64 Quad Core RadeonHD)

1:  Turn off Aero / Desktop composition.  This can be done in the compatibility settings in Win7, or to be safe, just turn off any and all desktop graphics enhancement at the system level.  Basically, if it looks like Windows 2k, you are good.

2:  Reduce your color depth to 16-bit instead of 32.  Most won't even notice the image difference, or it will be small enough that you can live with it.

3: Do not use "Transparency" at all.  Make sure it's unticked in the general options.

4: Make sure your touchscreen drivers do not have any support active for gesturing.  I was having the swipe occasionally not work and showing a forward and back icon.  The 3M drivers had apparently installed gesturing software which was competing with the swipe function.

A good read is this article, which describes how 2D acceleration, which was common to older graphics cards, has become poorly supported at both the system and the driver levels.  Nvidia seems to have an edge, but setting the machine up correctly can still provide usable performance with ATi cards. 

Also, there seem to be some bugs in the animation settings.  They often don't work as expected.  In my testing, I could see album animations still happening, which had been previously turned off and saved.  Also saw page scrolling, even when the swipe was set not to.  When scrolling, it also picks up an album width chunk of the background which is scrolled with it.  Some performance could probably be gained by constraining it only to the portion of the image where the actual album covers are.  I also get some bad judder as the scroll slows to a gradual stop.  I don't know if this slowing is intentional, or a byproduct of the additional pixels as it reaches the end.  If the former, a full speed to the end approach may be better.  An option for the coarseness of the scroll (i.e. number of pixels to move at each transition) might counterintuitively be smoother at a high enough speed.  It would, at minimum, make a snappier interface, albeit at a possibly less smooth movement.  Seems like a simple enough option to add for the user to decide which is best for their setup.

The obvious answer to all of this is to map the bitmap to a Direct3D or OpenGL surface, and do these types of transitions through leveraging of the 3D hardware acceleration.  Would make a big difference, and open up a lot more "bling" possibilities.

Barcrest

#1
Quote from: RandyT on December 10, 2013, 06:04:08 PM
When scrolling, it also picks up an album width chunk of the background which is scrolled with it.  Some performance could probably be gained by constraining it only to the portion of the image where the actual album covers are.

I just cut the chunk of screen and move it, I tried moving the individual covers only but it was even slower maybe due to moving multiple controls?

Quote from: RandyT on December 10, 2013, 06:04:08 PM
  I also get some bad judder as the scroll slows to a gradual stop.  I don't know if this slowing is intentional, or a byproduct of the additional pixels as it reaches the end.  If the former, a full speed to the end approach may be better.

This is due to the increase in image size scrolling on.

Quote from: RandyT on December 10, 2013, 06:04:08 PM
  An option for the coarseness of the scroll (i.e. number of pixels to move at each transition) might counterintuitively be smoother at a high enough speed.  It would, at minimum, make a snappier interface, albeit at a possibly less smooth movement.  Seems like a simple enough option to add for the user to decide which is best for their setup.

I thought I had an option in the animation settings?

Quote from: RandyT on December 10, 2013, 06:04:08 PM
The obvious answer to all of this is to map the bitmap to a Direct3D or OpenGL surface, and do these types of transitions through leveraging of the 3D hardware acceleration.  Would make a big difference, and open up a lot more "bling" possibilities.

This is the real answer and why there are not really many options in the way of eye candy. I had to pretty much make up for the lack of eye candy with additional features that are not found in other software. I tried some direct X stuff and I just couldn't get my head around it.
Keep on Rocking in the Free World \m/ ;D\m/



Jukebox Stats...

RandyT

Quote from: Barcrest on December 11, 2013, 09:24:05 AM
I just cut the chunk of screen and move it, I tried moving the individual covers only but it was even slower maybe due to moving multiple controls?

As you indicated that as more pixels become visible, the slower things become, perhaps limiting the screen grab to a chunk starting at the leftmost co-ordinate of all of the album controls and ending at the rightmost coordinate of the same, would reduce the burden a bit.  It might look a bit less odd as well, at least for layouts where the edges are fairly well aligned.

Quote
This is due to the increase in image size scrolling on.

Hmmm....  I have image controls that fly onto the screen in one of my VB6 applications, which don't seem to have this effect.  May I ask which type of control or the methodology you are using to do this?  There may be some simple changes you can make to really improve this.

Quote
I thought I had an option in the animation settings?

From what I was able to discern, these options don't do what I am attempting to explain.  The options seem to be "distance to activate swipe" and "delay between each position shift".    What I think would improve matters, would be a "coarseness" value.  Currently, you have "smooth scroll" attempt, shifting only one pixel at each repaint.  On a lot of systems, this single pixel shifting is going to be too slow to be of value.  I'm assuming your code is using a loop to bring the album bitmap to the correct co-ordinates.  By using a "step" command in this loop, and assigning the step value to the user's coarseness setting, this would increase speed with a possibly minor decrease in motion quality.  If the increase in speed was high enough, smoothness becomes less important.  Seems like a simple enough addition.

Not being critical, just hoping to be helpful.

Barcrest

The animation setting for the speed is under the animation settings not the swipe settings.
Keep on Rocking in the Free World \m/ ;D\m/



Jukebox Stats...

RandyT

Quote from: Barcrest on December 11, 2013, 10:13:28 PM
The animation setting for the speed is under the animation settings not the swipe settings.

There are no speed options in the animation settings which affect the swipe animations.  Are they supposed to?  If one of them is already supposed to be doing what I suggested, can you be more specific as to which one?


Barcrest

Seems like the sliders don't work as designed, they should do what you describe.
Keep on Rocking in the Free World \m/ ;D\m/



Jukebox Stats...