Closed Bug 940428 Opened 11 years ago Closed 7 years ago

[Call Log] Implement a streaming cursor based approach

Categories

(Firefox OS Graveyard :: Gaia::Dialer, enhancement, P3)

ARM
Gonk (Firefox OS)
enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: kgrandon, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [c=handeye p= s= u=])

See also: Bug 909935 Gaia would benefit a lot from a streaming cursor based list for performance reasons. The call log is one of the more simple lists we have in gaia. I propose that we implement a streaming cursor based list for call log first as a proof of concept. The goal here would be to remove the current limit for call log items, and allow for smooth scrolling across tens of thousands of entries. If we are able to show that we can do this, we can push for this solution in other places such as contacts, sms, and more.
Hi Etienne - Just wondering if you have any concerns/comments before we start working on a cursor-based implementation for the call log. If you'd like to meet over Vidyo to discuss this more we can certainly do that. Thanks!
Flags: needinfo?(etienne)
Hey, I'd love to see the cursor based approach works wonder here. And indeed this is probably a good place to experiment. That said, Ferjm is probably way more qualified than me to provide feedback on the indexed db backend of the call log, so forwarding :)
Flags: needinfo?(etienne) → needinfo?(ferjmoreno)
Can you elaborate more on this, please? Right now, the call log is also using a cursor based approach, where we render the list with small chunks of data ordered by timestamp, so the first chunk (with the most recent calls) is shown immediately. I am not sure that I am properly understanding the differences with a "streaming cursor based" approach. My understanding is that with this approach we will be rendering the piece of data that corresponds with the position in the list that is being shown in the screen. And I guess that we will keep rendering the following items of the list that are hidden but right after the piece of the screen that is being shown, unless the user scrolls up. Is that correct? (In reply to Kevin Grandon :kgrandon from comment #0) > The goal here would be to remove the current limit for call log items, and > allow for smooth scrolling across tens of thousands of entries. If we are > able to show that we can do this, we can push for this solution in other > places such as contacts, sms, and more. I would prefer to keep the limit for the call log DB as the reason for it is not only to avoid performance issues but also to avoid an endless growing DB. We can increase this limit though. Thanks for starting this Kevin! Please, let me know if you need any specific details about how the call log works. My memory is pretty bad, but I'll do my best to address your questions :).
Flags: needinfo?(ferjmoreno)
(In reply to Fernando Jiménez Moreno [:ferjm] (use needinfo instead of CC, please) from comment #3) > Can you elaborate more on this, please? I need to look into the code a bit more, but it sounds like the call log may be close to where we want to be. Ideally we'd have some library in shared/ which we can use in other applications. I need to flesh this out a bit more, but some rough requirements would be: 1 - Block fetching and rendering from an object which provides cursors. 2 - Aync reclaiming/reuse of off-screen nodes. 3 - Extensible and able to support things like jump links.
Hi, Some time ago I asked about implementing a similar thing, which is to have a 'universal' streaming list component that is flexible enough to use in Firefox OS different apps. I made a proof of concept here: https://github.com/sergi/virtual-list The main concern at that point was DOM performance, so it handles point 2 of Kevin's list. Implementing cursor handling and jump links should be relatively easy to implement on top of it. Cheers.
(In reply to Sergi Mansilla from comment #5) > Hi, > > Some time ago I asked about implementing a similar thing, which is to have a > 'universal' streaming list component that is flexible enough to use in > Firefox OS different apps. I made a proof of concept here: > https://github.com/sergi/virtual-list > > The main concern at that point was DOM performance, so it handles point 2 of > Kevin's list. Implementing cursor handling and jump links should be > relatively easy to implement on top of it. Thanks for the work on this, I will definitely take a look! I also had a rough prototype here: https://github.com/KevinGrandon/gaia/blob/contact_lists_2/apps/fastcontacts/js/cursor_scroll.js This is a bit outdated though, and needs to be cleaned up a bit.
Blocks: 865741
Whiteboard: [c= p= s= u=] → [c=handeye p= s= u=]
Priority: -- → P2
Hi Kevin, this bug just showed up in our bug triage. Could you update us on the status of this bug to evolve it if appropriate, please? Thanks! ;)
Flags: needinfo?(kgrandon)
I think this is still something that is worthwhile to investigate, and I was hoping to get to some more performance related topics early next year. Can we keep this around, but backlog it?
Severity: normal → enhancement
Flags: needinfo?(kgrandon)
Priority: P2 → P3
I'm adding this to our call log perf bug for 2.2 as this may be a potential strategy for eking out some perf.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.