On Thu, 12 Nov 2009, Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > > > But even if incremental blame turns out to be slower than incremental > > blame it still has the advantage of being _incremental_. You have at > > least some result soon. > > It wasn't it was slow that bothered me, but early implementations of > incremental blame I tried didn't _appear_ as incremental. That was the > dissapointing part. > > At the protocol and implementation level it certainly was feeding data > incrementally to the browser, but the end user experience on the screen > was "click....wait...wait...wait...voila the whole blame appears", not > "click...trickle...trickle...trickle...ah everything is filled". The > latter obviously is what an incremental one should be aiming for. > > No I haven't tried your latest code. Probably I should. The problem with earliest versions of incremental blame _in some browsers_ was that 'onreadystatechange' event was not fired as soon as new part of blame data was available (truth to be said the definition of this event is a bit underspecified). That is why newer versions of interactive blame use timer (alarm) to check every 1 second if there is something new. Perhaps interactive blame should use 'onprogress' event instead, which is well defined... but is in _draft_ of standard (XHR 2.0), and not yet in established standard. -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html