Open Bug 802170 Opened 13 years ago Updated 3 years ago

Google Tasks invalidation when typing

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
19 Branch
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: st4ck0v3rfl0w, Unassigned)

References

(
URL
)

Details

Typing an entry in google tasks (https://mail.google.com/tasks/canvas) repaints the whole page. The same effenct can be achieved when hovering over the menu symbols.
Blocks: dlbi
URL: https://mail.google.com/tasks/canvas
I can't reproduce it. Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0 buildID - 20121016013948 Try with new fresh profile with disabled addons and plugins. Attaching a screecast (e.g. http://www.screenr.com/ ) will be nice too.
http://www.screenr.com/DUV8 new profile, buildid 20121016030544
I can reproduce this. Is this a recent regression? Not sure how DLBI would have broken this. Look like there's a few bugs here. Firstly the call to InvalidateTableFrame in nsTableOuterFrame::Reflow isn't checking if the size actually changed, so we always invalidate everything. Once we fix that, then we get nsTableRowFrame::ReflowChildren and nsTableRowFrame::DidResize coming up with a different size for their child. So we're changing the size of the frame multiple times every reflow, and always invalidating everything. Not sure how to fix the latter, this seems like a fairly real tables bug.
No, this is no regression. It just is one of the few bad cases left after dlbi landed. This doesn't seem to be the only bug where table reflow is inefficient. Bug 318474 and the robohornet benchmark could profit from a solution. (just an uneducated guess)
Why do we still have the InvalidateTableFrame call there? I would have expected it to go away with DLBI... In any case, that code is definitely new with DLBI, right? > So we're changing the size of the frame multiple times every reflow Yes, that's the big problem with tables. Again, I had thought that DLBI would help here by deferring the invalidation until display-list construction, which happens after the size has stabilized.
> Yes, that's the big problem with tables. Again, I had thought that DLBI > would help here by deferring the invalidation until display-list > construction, which happens after the size has stabilized. Unfortunately DLBI is more or less disabled for tables. We require that frames build their own display items to paint their content, rather than defer it to another frame. Since tables generally don't do this, we have to work around and stick with the old code. Alternatively, when painting an nsDisplayTableBorderBackground we could walk the frame tree for the table looking for changed children. We'd also need the retained geometry to include rects for all table descendants, and add logic to detect additions/removals (which would be a duplicate of the core DLBI logic). I think it's better to work on getting table cells to always paint their own content, but that's not easy apparently.
> Unfortunately DLBI is more or less disabled for tables. OK. Generally speaking, we want to fix that, because table invalidation was one of the high costs of not doing DLBI... Are we still invalidating all over inside table reflow, then? Table cells always paint their own content. They just don't paint their background and borders.
(In reply to Boris Zbarsky (:bz) from comment #7) > > Unfortunately DLBI is more or less disabled for tables. > > OK. Generally speaking, we want to fix that, because table invalidation was > one of the high costs of not doing DLBI... Are we still invalidating all > over inside table reflow, then? Any idea who would be a good person to do that? I can try get to it at some point, but I have a fair bit to do, and I don't know the tables code. And yes, I didn't remove any of the table invalidation, just renamed it to the DLBI equivalents. > > Table cells always paint their own content. They just don't paint their > background and borders. Right, confusing terminology I guess. They need to paint all of their own 'stuff' :)
Not sure on person. Last to touch its reflow during invalidation was me, and I'm probably not a good choice here. :( roc, any ideas?
A variety of people could do this. However, I think we should focus on stabilizing DLBI-as-is for now and getting it into a shippable state in time to ship it, before we tackle this and any other non-regression improvements. Everything B2G-related is higher priority than this. Since this isn't a regression, it doesn't block DLBI.
No longer blocks: dlbi
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.