Jump to:
| Project: | Rotor Banner |
| Version: | 6.x-2.0 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (works as designed) |
Issue Summary
Hi,
I appreciate your good work on this module, and was pleased today to get a nice simple fading banner with 6 small images up on my remote site after some local trials (during which I'd noticed very sluggish response) .. until I discovered that this is a massive CPU hog ! With only one page open in either Safari3.1.2 or Firefox3.0.6 it consumed - with lovely CPU consumption peaks in my activity monitor at regular intervals corresponding to the time between images - something like 50% of a 2.5GHz Intel Core 2 Duo. With just a few browser windows open my machine was in pain. I can't do that to viewers of my live site.
Is this just fundamental to the technology, or is there in fact a real problem with the Rotor Banner implementation ?
Sorry to sound discouraging, I do appreciate your work and module, however I invested quite a bit of time in this and was very disappointed to make this discovery (I should have done better local testing during trials, too). Very glad for any feedback.
Whatever can or needs to change must change by nearly 100%. It is many many times too inefficient to be usable.
In the meantime, I am also looking into Views Slideshow and also SWF Tools + JW rotator, but they can't be combined nicely with links to specific target nodes.
Comments
#1
@webeb: I too have noticed quite a cpu hog with this module, but I'm pretty sure the problem actually goes deeper than the Rotor module. Rotor user the jquery.cycle plug-in and I think this is where the problem lies. I just assumed this was a feature (or bug) of using jquery effects like this. The ddblock module, which also uses jquery.cycle also has this problem, as does views_slideshow, which does not use jquery.cycle as far as I am aware.
I would certainly be interested to know if you find views_slideshow to be any less of a processor hog, but for me, a quick visit to its demo site (http://drupalhub.org/videos.) shows the same king of problem
#2
Yep, Views Slideshow is certainly a hog too. I could do a View Slideshow version on the same view keyed on Rotor Item to benchmark it properly. I may yet resume working with Rotor Banner, but for the moment I've switched it off on my live site until I investigate more. Thanks for interest and reply.
#3
Yes, this is a big problem. I like it very much, but had to tun it off...
Please do some upgrade!
Thanks
#4
Are you using the very latest version of jquery_plugin?
#5
Is this still an issue? I am using the latest jquery_plugin and I am planning to make some use of this module.
If this issue still exists, are there plans to solve it?
#6
@dddave, I would really love to see this fixed, but it really is out of my domain as the problem lies with the jquery.cycle library that this module depends on. Of course, patches are more than welcome!
#7
OK... 2 things:
1) update to the latest CVS code - I have made some tweaks to the JavaScript which should speed things up a little.
2) if you haven't already, install the 6.x-2.x version of jQuery_update - it includes a later version of jquery which features a much improved selector engine.
I have 2 rotors running on the demo site (http://rotor2.kirkdesigns.co.uk/) and I have definitely noticed improvements after doing the above - although, my CPU is still more active than I would like, but I think that's just the nature of this kind of jQuery.
#8
Appreciate your efforts to tackle this issue very much. But it may be worth a note that the update to 6.2 of jquery_update can cause some problems as noted here #358082: jQuery 1.3 in Drupal 6.x. So at the moment it may be some kind of pick your poison situation that resolves over the time.
#9
For more information, see these two links
http://groups.google.com/group/jquery-en/browse_thread/thread/4b575e112c...
http://groups.google.com/group/jquery-en/browse_thread/thread/5bb28de5e0...
Follow the advice given there and you will be able to avoid problems. This means, doing faster transitions, more frequently - but the trade off will yield better results.
I'm closing this ticket as there really is nothing I can do about it.
#10
subscribing