wolfzell;328826 Wrote: > Oh my. That makes iPeng nearly useless for me until then, since most of > my playlists do have 250+ tracks and iPeng/Safari is not only sluggish, > but also crashes a lot with those beasts... > > So I will keep waiting for new releases. Hopefully native... >
If you can live without using "shuffle" - that will help a LOT, especially on 7.1. Actually, I think as long as Apple is not fixing this native will be the only way around it since the issue is pretty fundamental: MobileSafari keeps only a small part of a longer page in memory and discards everything else. It discards it so well, that the biggest part of a long page is even removed from the active part of the DOM, and it also has to be re-rendered if it is about to be shown again. What iPeng 0.5 does is: it keeps the whole playlist in one big table. This is the only way you can do fast scrolling and drag'n'drop since you cannot interfere with the hardware accelerated scrolling and in any case changes to the page would be way too slow. Now if you do a change to that long list, and be it a minor one, means the part of the table that needs to be accessed has to be re-generated. For long lists, this is S L O O O W. As in absolutely, extremely, dramatically slow. For comparison: for a table with 250 rows, changing one text field in every row (re-numbering) will take like 2ms on Desktop Safari while it breaks the 10s barrier on Mobile Safari. That's a factor of 5000 or so!!!! Now I don't have a good way around this that would not either kill d'n'd and fast scrolling or be quite complex. I could do paging (only load 100 tracks at a time or so) but I prefer to work on native since my time is limited. If I can spare some more time I might check if I can further minimize access to the tables. As mentioned before, there's one thing that is EXTREMELY bad: using shuffle on SC 7.1ff. Why? When a track ends and you go to the next one, shuffle no longer increases the index (position in the playlist), but keeps the index at "1" and moves the whole playlist up one position. For iPeng that means the whole playlist is being changed! Pooh. That's where Safari (not iPeng) often crashes for long playlists. As I said: This has nothing to do with JavaScript or internal handling of data, it's pure DOM handling in the browser... So: let's go native... -- pippin --- see iPeng at penguinlovesmusic.com ------------------------------------------------------------------------ pippin's Profile: http://forums.slimdevices.com/member.php?userid=13777 View this thread: http://forums.slimdevices.com/showthread.php?t=49821 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/plugins
