Closed
Bug 1411937
Opened 7 years ago
Closed 2 years ago
Investigate render only chunk of messages that fits the viewport
Categories
(DevTools :: Console, task, P2)
DevTools
Console
Tracking
(firefox57 wontfix, firefox58 wontfix, firefox59 ?)
RESOLVED
DUPLICATE
of bug 1753177
People
(Reporter: nchevobbe, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 obsolete files)
In Bug 1391688, we'll do a first render with only the latest messages that fit the viewport, and then a second one with all the messages. What can be done is to only render what fits on screen, and then only render additional messages (not the cached ones) *until the user interact with the UI* (e.g., scrolls, click a filter button, enter text in filter output, …). When the user start to interact, a flag would be set in the store, and we'll render every messages. We can even mix that with having a requestIdleCallback to render cached messages as well, by chunks, so we don't lag too much when the user start to interact with the console. Say we have 1000 messages logged before opening the console. 20 messages fit on screen, so we render the last 20 message. New logs are added, and we render them after the 20 "cached messages" In the same time, we register a requestIdleCallback which would render the 20 * 2 last cached messages. Then we register a requestIdleCallback which would render the 20 * 3 last cached messages. And so on until all cached messages are rendered, or the user start interacting with the UI.
Reporter | ||
Updated•7 years ago
|
Comment 1•7 years ago
|
||
(In reply to Nicolas Chevobbe [:nchevobbe] from comment #0) > When the user start to interact, a flag would be set in the store, and we'll > render every messages. > > We can even mix that with having a requestIdleCallback to render cached > messages as well, by chunks, so we don't lag too much when the user start to > interact with the console. IMO we should try to render in chunks rather than waiting for interaction, since there could potentially be plenty of idle time to have rendered messages before any interaction. And if we don't it will pretty much guarantee the first click / scroll will be janky if there are lots of cached messages.
Updated•6 years ago
|
Priority: P3 → P2
Whiteboard: [console-html][triage] → [newconsole-mvp]
Comment 2•6 years ago
|
||
https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals
status-firefox59:
--- → ?
Reporter | ||
Updated•6 years ago
|
Summary: Render only messages that fit the viewport until there is a user interaction. → Investigate render only chunk of messages that fits the viewport
Updated•6 years ago
|
Whiteboard: [newconsole-mvp]
Updated•6 years ago
|
Product: Firefox → DevTools
Reporter | ||
Updated•4 years ago
|
Blocks: console-perf
Type: enhancement → task
Comment 4•4 years ago
|
||
Hmm, although react-window
can handle variable-height lists, we have to supply the height of the row in the render function. This is incredibly challenging. Here's a way we could do it:
- Cache all the rendered messages.
Bug 1659773 does this. - When a new message is supplied, render it without specifying a calculated height.
react-window
does not seem to provide a way to do this. We could possibly provide a too-high estimate for this and force a style ofheight: auto
, knowing that it will be fixed up in the next step. - After rendering the new message, capture the rendered size and feed it back into the cached data.
This invalidates the cached data for that message, but it's a one-time cost. Ideally the re-render that happens would be imperceptible as it would essentially just be setting the height of the row to a fixed value that matches its auto size. - If the console container is ever resized, clear the cache since all the message sizes would be incorrect.
Probably infrequent.
Huh, so maybe this is doable. I'll mark 1659773 as a blocker.
Depends on: 1659773
Comment 6•4 years ago
|
||
Depends on D87471
Comment 7•4 years ago
|
||
This is a very naive attempt. I locally built react-window, and took one of
the dist module files, renamed it to react-window.js and put it in the the
tree. It doesn't load.
Updated•4 years ago
|
Attachment #9170961 -
Attachment is obsolete: true
Updated•4 years ago
|
Attachment #9170799 -
Attachment is obsolete: true
Updated•3 years ago
|
Assignee: bwerth → nobody
Updated•2 years ago
|
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•