Long load times when using Node display type instead of field display type

I don't notice anything. I think I may have saw it on the first load, but I have cleared my cache and reloaded numerous times and I don't see anything now. Are you using a certain browser? I'm using FF3.5 at the moment.

Thanks for the response. I'm also on FF3.5, but have just looked on Safari and it's not happening there.

Must be a local issue so not to worry, am happy to close this assuming no-one else has this issue

thanks again

Actually, I have this same problem. Here's my situation:

Mac OS X (Snow Leopard) with Safari, Opera, and FireFox 3.5.3
VirtualBox running Windows XP with IE8, Firefox 3.5.3, Opera 10, and Chrome
Drupal 6.13 with Views Slideshow 6.x-2.0-beta2

I use Snow Leopard/FireFox for developing. I've set up two slideshows with nearly identical, very simple Views setups (filter by Content Type and Taxonomy, Node display, Slideshow display). Both Views are Panels panes and both are displayed via Panels.

One slideshow works beautifully, no problems. It's loading about 15 items, all text. I did have to upgrade from the Views Slideshow 1.x branch because I had an issue with only one slide loading. But I love the changes in the 2.x branch and I would like to keep using it rather than downgrading.

Second slideshow includes many more slides (around 60), each of which has a little text and one Imagecache-generated thumbnail. It seems that some browsers (such as FireFox on XP) don't show anything at all until the page is finished loading. However, when the browser displays things as they load, you get the problem described above, all the slides showing at once. I saw that with IE8 and Opera on XP and FireFox on OSX. With all browsers, the slideshow page takes a long time to load. With OSX/FF sometimes it takes so long there's some kind of Javascript timeout that spits out a warning. Also, I have the CPU spike issue as described in #397440: Spikes CPU in Firefox, Safari on slide transition (OS X). It pushes 100% sometimes!

My amateur guess is, when the slides are simple and few, they load and hide so fast you don't notice anything happening. But once you start doing Imagecache manipulations, dozens of images, lots of slides, etc. it takes so long that you do see what's going on.

Here's the page:
http://144.92.48.140/about/home

Is there any kind of fix for this? Any advice would be much appreciated!

Have you disabled the slideshow and the issue goes away?

Yes, if I set the View to another display type (like Unformatted) and the Panel to display 1 result at a time. Then it shows 1 randomly selected slide on each page load, as expected. I also tried other numbers, and it displays however many at a time, again as expected. I did notice that Panels doesn't respect the View's setting of how many results to display at a time. I was going to say that's a separate issue, but maybe it's related.

When I set up the slideshow, I set both the View and the Panel to display 0 (unlimited). I assumed the Panel setting worked the same way as the slideshow setting, i.e. if you set it to 1 you only get one slide and no cycling. Having set the View to display unlimited and the Panel to display 1, I can confirm that's how it works. Views Slideshow and Panels only work together if both are set to display unlimited results. Otherwise Panels overrides the Views setting and just displays however many results all at once. If the Panel is set to show 1, it will only show 1 and not cycle to other results. Too bad - I thought that might have fixed it!

Have you tried to add the slideshow on it's own page without using panels? I'm trying to eliminate panels as the culprit.

Since I had set it up as a Panels pane type, I didn't try it outside Panels. For testing, I set up a Page-type display within the same View (which is correctly handling a large gallery of thumbnails that all display at once - with attachments even!). Not only does the slideshow not work as its own Page, it gives me this: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 25382787 bytes) in /home/alrueden/drupal_loci-6.13/includes/common.inc on line 160

I tried several other display types too. That memory error only seems to appear when I'm using a Node type, rather than Field type, display. That is also how I was trying to display the slideshow. So I tried doing the slideshow Page with Fields - and it works! However, in the Panel, it does still show all the slides briefly before collapsing into one. It just doesn't take nearly as long as it did with Node display.

It seems it's only happening to me on first page load any subsequent load seems to work correctly. Do you find this a reasonable fix? I'm not sure why one would have to use the node display type.

Changing the title to better reflect the problem.

I'm seeing it every time, if I click over to another page on the site and then back. Tested also on my home computer (Windows XP/FireFox 3.5.3, Safari, IE8). In Safari it doesn't take so long to load, but you can still see all the slides while it is loading. Which is weird, because this doesn't happen with the other slideshow on the home page. That one doesn't have nearly as many slides or any images, though.

The reason I'm using Node display is because it produces those nice little boxes with the headline and read more link. I'm using it all over the site, and I'd rather keep the look consistent. The Fields display has no inherent style and would take some work to be presentable. If it comes to that, I'll just set the Panel to display one slide at a time and backburner this particular slideshow.

Is it possible it is the jquery plugin for making rounded corners? It seems it may take a while with so many boxes?

I agree that the Jquery plugin does cost some load time, but I tried turning it off and still had the same general problem - long load time, all the slides are visible during that time.

Ok I just tested this with my local installation. I am using node type and 100 items. I do not notice any issues. I can hear my fan kick up, but the website never stalls. I do notice the problem on your site so the problem exists somewhere, but I'm not quite sure what the problem is.

The thing is, I didn't have this problem with the 1.x branch. This same slideshow was working fine before upgrading. That leads me to believe the problem is caused by some change between the versions of this module...however, the other obvious cause would be performance issues. The site is large and has a lot of modules, plus that particular node is quite complex. I haven't done any work on improving performance, so I'll look into that and see if it helps. Do you have any recommendations on what caching settings would work best with Views Slideshow? Thanks for all your help!

I didn't notice the problem when I looked at your site, but this sounds a lot like this issue:
http://drupal.org/node/610184

If that's what's going on I've seen it with happen with as few as 5 slides, and using field display type instead of nodes. This is over a (not so fast) VPN and the site uses lots of JS. It seems that if the CSS is not loaded in hook_init(), you will see every slide displayed in a big list until the JS kicks in.

On my own site I have the CSS loaded via hook_init() (so I can use block caching), and with the CSS loaded that way I NEVER see all of the the slides displayed in a list, even when doing a full refresh over my VPN.

@alrueden: As far as caching goes, all caching options work well except for block cache. Currently with block caching enabled you need to configure the block to be cached per page (or per role, per page if using authcache), or the JS/CSS will not get loaded when the block is loaded from cache. See http://drupal.org/node/404894 for a potential solution if you want to have the block(s) cached globally. It works great for me. ;)

Yes, #610184: Prevent Preload of all Thumbnails? is a duplicate of this issue. Is this going to get fixed? Because the module is unfortunately unusable to me in its current state. It also causes some slowdown even on pages where it otherwise works fine. Probably your fix at #404894: Block caching prevents the javascript from always being loaded will help both issues, but I won't be around forever to apply it every time the module updates. I would really like to continue using this module, but I can't unless there's a solution on the horizon.

Unfortunately I don't have enough cycles at the moment to get it done. I will eventually fix it. But my projects are stacked at the moment. I will try to get to them as soon as I can.

All right, thanks for the update! I'll keep following your progress.

subscribing