cpu spikes when using slideshow in block

Same problem..

Is it perhaps possible to set the speed of slideshow by way of specifying seconds, even if programmatically? I have set 'slow' but it is too fast for my liking, and the CPU load is directly related to that.

subscribing

Try optimizing the view as it may be slow by itself and only gets worsened by showing it repeteadly.

From what I can tell by inspecting the final page source, all the items in the slideshow are loaded in the page at the time the page is created, and CSS style manipulation is used to show / hide them. If that's true, then the server is not affected by the speed of the slideshow in these cases.

What will affect server load in this case (and lengthen page load time) is the number of items in the slideshow.

The speed (delay time) of the slideshow may affect the user's computer, though, as the JS cycles through the functions called by the timer more often with shorter timers.

But, in the latest version of the module, you can give the delay in actual numerical value (milliseconds). Is the Fade speed that you're referring to when you say you have yours set to "slow"? You may be able to do something with this programmatically by putting some JS in the header of the block. Check out the fadeTo() method for possible options to the fade_speed property.

To troubleshoot, you can also try increasing the Fade value or turning off fading to see if it makes any difference.

@kentr -- interesting. The spike is then surely related to the browser trying to load all the "slides" at once. I think that's dangerous -- the server could choke if it's to produce say a thousand or more "slides".

I wonder if the author has been considering loading the "slides" on request, and not all of them at once...?

There are 2 issues here. The first is server-side, the other is browser-side.

Those suffering a server-side spike should make sure that the view is cached. Go to admin/build/views/list and click on the Edit link for the view containing the slideshow. Click on the 'Block' display in the top left, then under 'Block settings', change the 'Caching' setting to 'Cache once for everything (global)' then save the view.

Browser-side is entirely dependent on the client's capabilities but turning the fade option off should help slower computers. Fading adds about 20% CPU load to my browser.

@vacilando: Yeah, it would be an issue with a large number of images. I'm guessing you can get sort of workaround for this by setting the number of images displayed in the slideshow to a lower number and using the random selection functionality. Dynamic loading would be great. I've thought about looking into that as well.

@kentr: sure, but limiting the number of images and setting random on is just an emergency, unsatisfactory solution. Doing that means that your sub-selection of just x images will sooner or later start looping, while the dynamic loading solution would provide true slideshow of all images over time (great for presentations / demoing right off the website).

It's encouraging to hear you've been thinking about looking into it!

@vacilando: Is your view cached as I described? Are you using private files instead of public (ie. are images restricted to being served only via Drupal's system/files mechanism)?

Simply serving images from the web server should have negligible effect on the CPU load as all it should be doing is little more than direct I/O from the disk onto the network interface.

Using Drupal's private files mechanism will cause a significant overhead as every file (image) request does a full process of the PHP interpreter. Don't use Views Slideshow with private files!

Fleshing out what you are hinting at, are you suggesting an AJAX call to download slides? Remember VS can be used for any view content, not just images.

@wad:

That's the sort of thing I was thinking. Mod the code to just load a list of images, but not the images themselves. Then, the next couple of images in the slideshow could be staged in hidden <div>s as they are now, but not all the images. Timer function not only sets next staged <div> slide class to visible, but also re-writes the next non-staged image into an actual <img> tag so that the image itself gets loaded at that time.

There are some other possible solutions or additional optimizations I can think of:

• Force the slideshow data to the end of the page, so that it only loads after the content. This could probably be done by templating & absolute positioning, but it would be nice if this feature were an optimization option.
• Piggyback onto the ajax paging system to have slides loaded / staged as a group (again, after the bulk of the page content loads). I'm guessing it would probably be pretty easy to activate the "next" button of the paging system via jquery. Timer function cycles through the loaded "page" of slides, and at the end of that "page" actives the "next" button of the pager to load the next group. Perhaps if necessary to have a "cycling" group separate from a "staged" group, follow the disk swap space model: dynamically copy the HTML of each new loaded "page" into the HTML structure that the slideshow cycle functions are working with.

So option 1 I don't think would be useful to most people using views slideshow because it would require them to do significant styling work to get it to show right.

Option 2 has been mentioned here: #323366: Ajax loading support

FYI: Server load issues are more than likely something other than views_slideshow. Browser side issues are likely to be views_slideshow related, but is more than likely the nature of the beast.

Marking as duplicate.