<div class="gmail_quote">On Fri, Jun 18, 2010 at 6:12 PM, Jakob Leben <span dir="ltr"><<a href="mailto:jakob.leben@gmail.com">jakob.leben@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div class="im">On Fri, Jun 18, 2010 at 2:35 PM,  <span dir="ltr"><<a href="mailto:git@videolan.org" target="_blank">git@videolan.org</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
vlc | branch: master | Ilkka Ollakka <<a href="mailto:ileoo@videolan.org" target="_blank">ileoo@videolan.org</a>> | Fri Jun 18 15:35:04 2010 +0300| [926bbf142f297f9715e3cc5ad746b98a448c3451] | committer: Ilkka Ollakka<br>

<br>
Qt4: don't do playlist_model recursive remove as core signals for those anyway<br>
<br></div><div class="im">
+ * Lets not worry about nodes children, we do refersh anyway when<br>
+ * core tells that playlist has changed, should give some more speed<br></div></blockquote></div><br></blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Speed? I am sure it's faster that PLModel::recurseDelete() removes items to delete from the selected list, than making a route through the core back to Qt for every of those items (thus searching by ID at the core side and again back at the Qt side).<br>

</blockquote></div><br><br>Plus, your commit makes more playlist lockings than before, so it is less efficient in that sense as well.<br>