On Sun, Mar 30, 2014 at 5:39 PM, Kartikaya Gupta <[email protected]> wrote: >> 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.
The first thing we need to do to get APZ on desktop is to enable out-of-process running on B2G desktop. The first step to get *that* happening is to start testing the gfx code out-of-process. This is tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=922680 Like Alexandre pointed out, there's no need to wait for Mulet to get these things working. If we make B2G desktop run out-of-process then Mulet will immediately benefit from that. >> 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! :) Mulet will make it easier for us to land things in gecko which makes Mulet behave more like on-device. For example rather than using addons to simulate touch events, I think it should be doable to make gecko use the same code paths for touch event generation in Mulet as we do on device. But Mulet will never be an alternative to testing on device. If for no other reason that we can't accurately mimic performance characteristics of a device. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
