Closed Bug 649440 Opened 13 years ago Closed 13 years ago

Fire OnStopFrame notifications per-'frame' (draw-request) in SVG images

Categories

(Core :: Graphics: ImageLib, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla6

People

(Reporter: dholbert, Assigned: dholbert)

References

Details

Attachments

(2 files, 2 obsolete files)

Joe says in IRC that we should be firing OnStopFrame notifications for SVG Images - that'd make testing animated vector images easier and more consistent between vector & raster images.

We probably want to do this with the existing FrameChanged call here:
> 712 VectorImage::InvalidateObserver()
> 713 {
> 714   nsCOMPtr<imgIContainerObserver> observer(do_QueryReferent(mObserver));
> 715   if (observer) {
> 716     observer->FrameChanged(this, &nsIntRect::GetMaxSizedIntRect());
> 717   }
> 718 }
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
Taking, so I don't lose track of this -- I hope to follow up in the next week or so.  (Feel free to steal this, though.)
Attached patch fix v1Splinter Review
I believe this is all that's needed here.  (I've thrown in a few MOZ_LIBXUL ifdef removals in VectorImage, too.)

I'm actually not sure how to test this, though.  (but once I find out, I'm hoping it'll help with randomorange fixing in bug 612214!)  IIUC, I should be able to implement the imgIDecoderObserver interface in JS, and somehow register to receive callbacks, but I'm not sure how to register.

It looks like modules/libpr0n/test/unit/image_load_helpers.js is the only testing code that tries to do something like this right now, but I don't think it's quite the same as what I'd need to do.

joe, any tips on how I'd register to receive OnStopFrame notifications in a test? (in a mochitest-chrome test, I presume)
Attachment #526870 - Flags: review?(joe)
(In reply to comment #2)
> joe, any tips on how I'd register to receive OnStopFrame notifications in a
> test? (in a mochitest-chrome test, I presume)

CC'ing bz in case he can help on the above. (I think I want to do what bz suggested in bug 641198 comment 24 -- but per comment 2, I'm not sure how, and I can't find any tests to crib from. :))
Assuming you have an <html:img> or some such, QI it to nsIImageLoadingContent and use addObserver on the result to add your imgIDecoderObserver.  You may need to removeObserver by hand to make sure you don't leak; I dunno that we cycle-collect those (we probably should).
modules/libpr0n/test/unit/async_load_tests.js is another, utterly over-the-top way of getting those callbacks (by calling LoadImage manually and passing your own object as the observer). But Boris' suggestion is much much better.
Comment on attachment 526870 [details] [diff] [review]
fix v1

I would not cry if the MOZ_ENABLE_LIBXUL changes were in a separate patch in the final push.
Attachment #526870 - Flags: review?(joe) → review+
(In reply to comment #6)
> I would not cry if the MOZ_ENABLE_LIBXUL changes were in a separate patch in
> the final push.

I've split them out locally, to NS_ENSURE(joe_will_not_cry). :)
Attached patch test as patch (obsolete) — Splinter Review
Here's a test patch.  This burns down the orange monstrosity that is img-anim-1.html, and from its ashes creates a beautiful mochitest-chrome jewel.
Attachment #528179 - Flags: review?(joe)
Blocks: 612214
Attached patch test as patch (obsolete) — Splinter Review
(this version adds a missing semicolon - didn't affect functionality, but should be there for consistency)

BTW, the stub implementations on ImageDecoderObserverStub probably aren't 100% required, but they're good for cleanliness, because otherwise get get ugly error-spew in the terminal (and probably in the error console too) every time we attempt to call a nonexistent imgIDecoderObserver method on the object.

ImageDecoderObserverStub is basically taken directly from libpr0n/test/unit/image_load_helpers.js, with all the impls replaced with "{}".
Attachment #528179 - Attachment is obsolete: true
Attachment #528179 - Flags: review?(joe)
A few other clarifying notes on the test patch:

 - When reviewing, start reading in "main()" (at the bottom of the mochitest).  Hopefully it's pretty self-explanatory.

 - I upped the animation-duration in lime-anim-100x100.svg from .001 sec to .1 sec, since (unlike img-anim-1.html) the new test doesn't rely on the animation completing near-instantaneously.  (I could up it more, of course, but I don't want the test to take up too much time.)

 - The mochitest references bug 610419 rather than this bug, since that's what img-anim-1.html was testing.

 - I made the mochitest intentionally time out after 120 seconds, rather than falling back on the harness-imposed timeout, so that in the unlikely event that we take that long, we can print a little extra debug information.
(In reply to comment #7)
> (In reply to comment #6)
> > I would not cry if the MOZ_ENABLE_LIBXUL changes were in a separate patch in
> > the final push.
> 
> I've split them out locally, to NS_ENSURE(joe_will_not_cry). :)

And then you went and wrote that comment, and now I will cry all the time.....
d'oh! apparently when I posted the updated version of the test patch, I forgot to request review on the new version.

So, as long as I'm adding a review request now, I'll add one more marginal tweak -- I've just made the snapshotWindow() calls more consistent (always passing false as the second "withCaret" argument, rather than omitting it).
Attachment #528182 - Attachment is obsolete: true
Attachment #528371 - Flags: review?(joe)
(btw, this bug's fix + test had 2 full-green mochitest-oth runs on TryServer yesterday.  I'm doing another TryServer run of the test w/out the fix right now, and it's failed as expected (hitting my internal timeout) on the one mochitest-oth cycle that's completed so far.)
Comment on attachment 528371 [details] [diff] [review]
test as patch (now with more consistent snapshotWindow calls)

Looks lovely! Make sure that style.display = "none" is done synchronously, though.
Attachment #528371 - Flags: review?(joe) → review+
It's async in general, but certain operations will force it to be processed; taking a snapshot of the window is one of those.
Landed the patch, split up as requested in comment 6:
   http://hg.mozilla.org/mozilla-central/rev/340131166fbc
   http://hg.mozilla.org/mozilla-central/rev/cdbeb9df92d3
and the test:
 http://hg.mozilla.org/mozilla-central/rev/3b1fa83ffc99

(I made a minor tweak to the test before landing, as I mentioned to joe on IRC -- I just delayed the initialization of gMyDecoderObserver so that it gets set up all in one place, and tweaked some comments accordingly)
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
The tests patch here copied "lime-anim-100x100.svg" from reftests over to mochitests, and I just realized that the reftests version of this file is now unused (as shown by the following mxr search, which only turns up references in mochitests):
http://mxr.mozilla.org/mozilla-central/search?string=lime-anim-100x100.svg

Pushed a followup to remove the old/unused reftest copy:
  https://hg.mozilla.org/integration/mozilla-inbound/rev/fa06ce52a09e
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: