Asynchronous image loading in layout

[Josh Matthews]

I'm in the process of removing all traces of synchronous image loading
from Servo, building on top of one of this quarter's NCSU projects. I'm
dealing with a test failure right now where I understand the problem,
but I'm currently stumped on how to solve it, so I'm open to ideas.

THE PROBLEM:
<style>li { list-style-image: url(smiling.png) }</style>
<li></li>
<li></li>

In the old reftest world, image loads were synchronous to avoid problems
with taking screenshots before the images had appeared. In the new
world, laying out the first list element triggers an asynchronous
request for the image. If the scheduling works out right, the image is
loaded and decoded by the time the second list element is laid out, so
it's fine. In my current code, the first element increases an atomic
counter indicating the number of pending image requests.

At some point in the future, the image cache notifies the layout thread
that an image was completely decoded, so we decrease the counter. The
existing code in LayoutThread::handle_request (Request::FromImageCache)
then calls `self.repaint`, but this does nothing for us - the first list
element doesn't have any image to repaint, and there's nothing tying the
completed image to that particular element. Thus, we proceed to take a
screenshot of the page, but the first list element is missing its image.

For images where the load is initiated via the script thread, we have
the Trusted<HTMLImageElement> mechanism that ensures that the element
remains alive so we can interact with it as image data is received.
There are no such guarantees in the layout thread - the script thread
could remove the list element from the document right after layout
completes and trigger a GC, before the layout thread gets any image load
notification. I'm not sure what to do here - the layout thread seems to
need to initiate a reflow in certain situations, but I can't figure out
how to limit the damage to relevant nodes.

Cheers,
Josh

[Matt Brubeck]

In ancient double-digit-issue times, our forefather brson suggested that we
could store some sort of promise or future in the display list, for images
pending load:
https://github.com/servo/servo/issues/43

Would something like this work? It might make sense to store the futures
in the flow tree instead of (or in addition to?) the display list. The
future would contain sort of identifier that corresponds to an image
request. Each time layout runs, any "image future" fragment would check to
see if its request was now finished. When any image load completes, we
could trigger a layout pass that triggers these checks. (This could use a
new RestyleDamage flag, or maybe just make sure these fragments have an
existing flag like REPAINT set for as long as they contain an unfulfilled
future.)

[Patrick Walton]

Display lists are serializable, so it seems difficult to store futures
there. The Fragment seems like the natural place for them. I concur with
mbrubeck that some kind of future seems like the right solution here.

Patrick

> _______________________________________________
> dev-servo mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>