On 12 February 2013 13:05:33, Jean-Marc Desperrier wrote:
Matt Woodrow a écrit :
to improve both performance and responsiveness of the browser, we are
planning on moving painting to happen on a separate thread.
I think you should take some time to consider what impact it has on
the synchronization between interactive events and what is visible.
- Browser receive the order to draw Y above X
- I click on X that I'm still seeing
- Browser asynchronously actually draws Y
What does the browser consider I clicked on ? It may happen that the
browser considers I clicked Y while I was seeing X.
Especially if the intend is to improve responsiveness, which means
that I can click whilst the browser is painting, so it may be unclear
what I intended to click on.
I'm not sure this situation is really affected at all. This would be an
issue currently with just OMTC, as well as under the proposed scheme.
A similar situation that could happen is that you scroll down and the
page changes in response to the scroll change. This would still be an
issue with current asynchronous compositing, but the difference is you
may get to an area with just OMTC that would be blank, where as it
would more likely be visible (and incorrect) under this scheme. Neither
of these situations are an issue until rendering takes a significant
amount of time, though.
The proposed scheme might actually make this easier to fix. We
currently do hit detection by drawing a pixel of the display list (I
think?) and seeing what gets drawn. If we're separating the display
list from external dependencies, we could theoretically use it for hit
detection so that there isn't a mismatch between what's on the screen
and the current Gecko-side state.
I think it'd be more sensible to look into this if it ever becomes an
issue, but certainly something to consider.
--Chris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
