On 29/3/2014, 22:26, Vivien Nicolas wrote:
So all the events are emulated from mouse events as of today in order to
generate touch events, that are forwarded to BrowserElementPanning.js
that does sync scrolling.
So basically none of the APZ code path :/
Ok, thanks for clarifying.
I assume that the patch you're speaking about that may break the Mulet
is about moving events to a separate thread ?
No actually the patch I had in mind was
https://bugzilla.mozilla.org/attachment.cgi?id=8398661&action=diff -
there's some code in APZ that is supposedly there for B2G emulation but
I've never seen it exercised. I thought maybe Mulet might start using it
right when I get rid of it.
So to summary for the moment the Mulet has a lot of flaws. Especially
related to touch events, for the RIL backend, and NFC backend, Audio, etc..
But it is already a big progress in terms of unified dev environment for
many and it basically combines the advantages of 3 of the 4 different
developers environment we have today (it combines b2g-desktop, the
simulator, and Gaia extensions to develop in the browser, but does have
use all the widgetry of the device).
I totally agree that something like this will be very useful, but it's
important to make it clear which parts are representative of what will
be running on-device and which parts are not. If any users of this tool
assume that the panning behaviour will be the same as on-device, they
will be in for a surprise. I think there are legitimate scenarios where
users may write apps with heavy painting and see no checkerboarding in
Mulet but then get heavy checkerboarding on-device, for example.
I look forward to trying this out as soon as I get a chance! :)
kats
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
