598435 - trigger thumbnail update with MozAfterPaint?

Status: RESOLVED DUPLICATE of bug 659594

(Firefox Graveyard :: Panorama, defect, P3)

Description

[Ian Gilman [:iangilman]]

We're currently using TabAttrModified to trigger our thumbnail updates, but several people have suggest we should be using MozAfterPaint instead (possibly along with page load events). Worth exploring if this would make us more reliable and/or efficient.

Comment 1

[Aza Raskin [:aza]]

This seems like it should be part of the performance investigation work?

Comment 2

[Ian Gilman [:iangilman]]

An email thread on the subject:

>> On Aug 15, 2010, at 11:19 AM, Bobby Holley wrote:

I was just testing things on trunk (where don't yet lock images at all, because I haven't quite landed bug 512260).

Normally the appropriate way to test would be to set image.mem.discard_timeout_ms to 2000 or so, load some pages with images, and then switch to other tabs. Unfortunately, I think retained layers is doing a good job of caching image layers, which makes it more difficult to analyze.

So the better solution is to enable image.mem.decodeondraw, and ctrl+click on links to open them in background tabs without ever viewing them. This guarantees that the images will not be decoded (you can verify this by control-clicking on a link to a large image, like the test url for bug 583825, and then tabbing over to watch it decode).

Using tab-candy with this, it seems like large images do eventually get displayed, after about 4 or 5 seconds (at least for me). This isn't the worst thing in the world, but it could also be better, since I'm pretty sure the images are actually decoded sooner than that. I think some experimentation with MOZ_AFTER_PAINT is in order. I can't compare with aero peek because I don't have windows...

Also, are you rendering via RenderDocument, or something else? I added a flag in bug 578511 to make it possible to disable sync decoding of images when doing RenderDocument (they're sync decoded by default because people usually expect that when they drawWindow), but it doesn't seem to me like tabcandy is hanging on a sync decode.

So those are some general ramblings. Hit me back with any questions.
-bholley


>> On Aug 12, 2010, at 11:59 PM, Rob Arnold wrote:

MozAfterPaint is what you want to listen for. See the Aero Peek code for examples of how we use it to track the invalidated region. Note that it gives coordinates in that of the document so for zooming, you'll have to slightly clever when it comes to redrawing those areas. The Aero Peek code doesn't handle this correctly but there's a patch in bug 520943 which handles zoomed pages.

-Rob


>> On Fri, Aug 13, 2010 at 2:48 AM, Bobby Holley <[e-mail]> wrote:

The tabcandy solution here should be similar to the aero peek one. I've CCed rob to provide insight.

So basically, whenever something that is drawn to the screen changes, it does an invalidate call to the layout machinery telling it that a certain rectangle is no longer valid and that it needs to be repainted. You're going to want to update the canvas based on that, because when you first draw an offscreen tab its images are going to be blank (try setting image.mem.discardable to true to see what I mean). I'm not sure of the high-level event that you need to listen for, but Rob probably does. Rob?

Cheers,
-bholley

Comment 3

[Kevin Hanes]

bug spam (moving to b10)

Comment 4

[Kevin Hanes]

bug spam

Comment 5

[Michael Yoshitaka Erlewine [:mitcho]]

Unless we see a very compelling perf reason to do this, we should punt on this for fx4.

Comment 6

[Ian Gilman [:iangilman]]

bugspam: returning Sean's bugs to the pool

Comment 7

[Tim Taubert [:ttaubert] (inactive)]

Bug 659594 transformed into the MozAfterPaint work. We'll handle this bug over there.