Worse performance if full width is used on mobile device about slider HOT 23 CLOSED

What's your chrome version? And Android version? And WebKit version?

from slider.

Chrome 38.0.2125.102 on Android KitKat 4.4.4, Qualcomm Snapdragon 800, Krait 400, 4x2.27 GHz, Adreno 330

from slider.

I see.
Please set $HWA to false and then check the performance with your browser.

from slider.

Does not seem to make any difference whether I set it to true or false.

Here's a screencapture: http://youtu.be/2ELWhF0SUhE

Could it be related to the zoom settings? Maybe this should be used for mobile devices:

<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no">

It could also be the JavaScript that automatically adjusts the slider width to the viewport width, maybe there are too many resize events handled. It should be enough to check like every 250ms for a change and abort if viewport width is still the same.

from slider.

As the resize event be handled while window resize only, it should not be the reason.
And note that responsive settings are all the same for full width slider and other sliders.
I will investigate this issue.

Many thanks!

Btw, as you said it happens only on full width slider. May you compare the performance between 'simple slider' and 'slider with slideshow'?

from slider.

Simple slider runs smooth as butter, slider with slideshow is a bit choppy, but the full-width example is way worse (slider with slideshow does never hang, in contrast to the full-width one).

What is the difference between both?

Overlay cover works great, except that there are thin lines around the borders:

Choppy examples:

• banner rotator 2
• banner slider
• different size photo slider
• image gallery
• image gallery with vertical thumbnail (very sluggish!)
• simple fade slideshow

All other examples work very well!

from slider.

Would actually be great to get some performance tips. I tried a simple slideshow on Chromecast and it keeps crashing. It has plenty of images, but I am using src2 for lazy loading of images. Still crashes. Any performance tweaking tips, would be appreciated.

from slider.

@husayt Do you display the slider on TV? What's the screen resolution? And screen refresh rate (60HZ, 75HZ etc.)?

from slider.

Hi @jssor,
I am using chromecast to displlay show on Tv or Lcd monitor. Now i just had
updated to latest version and got HWA off. Seems more stable now.

Will try more and see how it goes.

Thanks for great library.
On 15 Oct 2014 00:34, "jssor" [email protected] wrote:

@husayt https://github.com/husayt Do you display the slider on TV?
What's the screen resolution? And screen refresh rate (60HZ, 75HZ etc.)?

—
Reply to this email directly or view it on GitHub
#51 (comment).

from slider.

@CoDEmanX

It seems there is a big improvement when I use RequestAnimationFrame (jssor.js line 2463) to play animation.

Please download the test package and have a test. http://www.jssor.com/jssor.slider.testpack.zip

Please double check $HWA option for full width slider. And make sure to clear browser cache when you swith $HWA option.

from slider.

Can't see any difference.

Turning HWA off breaks the slider completely:

var options = {
            $HWA = false,
            $FillMode: 2,     

from slider.

It is not HWA, You are using '=' instead of ':'
On 15 Oct 2014 07:40, "CoDEmanX" [email protected] wrote:

Can't see any difference.

Turning HWA off breaks the slider completely:

var options = {
$HWA = false,
$FillMode: 2,

—
Reply to this email directly or view it on GitHub
#51 (comment).

from slider.

Ah, right.

Please replace $HWA = false, with $HWA: false,

from slider.

Doh, of course!
But with HWA off it's even choppier, if turned on not as bad but still rather sluggish. How is it possible?

Most of the other examples work great, and it doesn't really matter if you zoom in or not. With the ones I listed above, it gets more choppy the more I zoom in.

from slider.

I tested again with Samsung galaxy note 4.
It works ok.

Chrome 38.0.2125.102
Android 4.4.4; SM-N9100 Build/KTU84P

from slider.

OK, let's investigate the full width slider then.

The full width slider uses large dimension images. Please use smaller images (which were used in other examples) to have a test.

Also, what's performance with the native android browser instead of chrome 38?

from slider.

Please try to remove content in slide and simply keep the main image in the slide.

from slider.

Maybe it's just the image dimensions, that definately possible. VRAM is limited, so they might be too large for the GPU to get full HWA. Will try lower res images.

Chrome for Android is my native browser, I can try Dolphin and Firefox however.

I can try without content, but I doubt that's causing that much issues, because the animated captions work super smooth.

from slider.

Wow, I didn't expact this: I removed the slide contents and it went to high-speed. Then I added back the static captions - and dang: choppy as hell!

I tried text-rendering: optimizeSpeed; http://css-tricks.com/almanac/properties/t/text-rendering/
but didn't help anything.

So I added the null-transform hack directly to the text divs and it became very fast again.

My conclusion: text rendering, especially while zoomed in, is very expensive in combination with translating things around, maybe it's the text + slider image compositing?

The animations in the slide content are silky smooth, it's choppy if I swipe however. I believe it's the text again, not the animation of imgs.

Another reason could be layout trashing: http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/

Ideally, static text + slide background would become a single texture that is uploaded to GPU for great performance, and additional content put on top, but maybe in groups too so it can be animated as a whole (translate, rotate, scale, change opacity). I dunno what Chrome is actually doing, whether it combines the text + image into one compositing layer with the null-transform hack applied, or if they are kept separated all the time and blended together later on...

from slider.

Great Job, Cheers!

I will go for some test cases later.

Thanks a lot!

from slider.

I guess you added '-webkit-transform: translateZ(0)' to text element.

What about '-webkit-transform: perspective(2000px)' instead?

from slider.

I tried all three combinations of perspective: 2000px and transform: translateZ(0) and it only boosted performance when I used both at the same time.

I did not use a browser prefix (-webkit-).

-webkit-transform: perspective(2000px) doesn't look right, I assume you mean -webkit-perspective: 200px? http://www.w3schools.com/cssref/css3_pr_perspective.asp

Remark about the "go faster" hack: http://aerotwist.com/blog/on-translate3d-and-layer-creation-hacks/ (limited VRAM may not be a concern on your Galaxy Note or my Nexus, but other less powerful devices)

from slider.

For hwa, i used 'translateZ' at the beginning. And later changed to 'transform: perspective: (2000px)' to improve performance for Safari 5.1.7 (windows version).

I didn't realize 'perspective: 2000px' before. It may be the correct way then.

I disabled HWA for chrome (temporarily) now to prevent low performance devices from crash.

I will investigate more and then enable HWA for latest devices (maybe android 4.4 or later). And allow user to disable HWA manually by setting $HWA to false.

Thanks again!

from slider.