Re: Largest chunks of code that are likely to be removable?
On Tuesday, June 30, 2015 at 3:41:43 AM UTC-4, Kearwood Kip Gilbert wrote: Would anyone be opposed to combining the Matrix4x4 class and gfx3DMatrix? Rather than adding support for transforms and projections that involve vertices behind the w=0 plane to gfx3DMatrix, it may be cleaner to refactor affected call-sites to use Matrix4x4 instead. The remaining references to gfx3DMatrix would be very few and easily replaced as well. I think dzbarsky was in the process of converting gfx3DMatrix use to Matrix4x4, I'm not sure what happened or if he's still working on it. I think people would be quite happy if you finished it off. CC'ing dzbarsky to see if he has any updates. kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revisiting modelines in source files
On Thursday, June 18, 2015 at 8:36:09 PM UTC-4, Eric Rahm wrote: Can we sidestep this by punting on enforcing a line length restriction with clang-format? I think it would be reasonably uncontroversial to just do the following initially: - spacing - indentation - bracing If we can do just this, I'm all for it. I just did another test run of clang-formatting the APZ code and if I ignore the line-length stuff I don't see any issues (I only skimmed the results though). kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revisiting modelines in source files
On Wednesday, June 17, 2015 at 9:57:12 PM UTC-4, Gregory Szorc wrote: First thing is first: what are the blockers to mass rewriting mozilla-central with clang-format's output? For the record I'm in favour of auto-clang-formatting the codebase, but the last time I tried running clang-format on the APZ code [1] there were at least two issues: 1) Comments that exceed the 80-char limit get wrapped blindly, rather than being rewrapped properly. This results in comment blocks that look like this: // This is a comment that was previously just over the eighty // character // limit but got rewrapped by clang-format just blindly // inserting // linebreaks willy-nilly and requires manual fixup. I think this is an issue that should be fixed in clang-format. However, to work around this incrementally I have been manually rewrapping comment blocks in the APZ code if I'm touching them anyway. 2) MOZ_BEGIN_NESTED_ENUM_CLASS seems to trip up the formatter and it misformats the code after that. Cheers, kats [1] https://bugzilla.mozilla.org/show_bug.cgi?id=971970 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The War on Warnings
4606 [N] WARNING: No widget found in TabParent::UpdateDimensions: file dom/ipc/TabParent.cpp, line 974 Do you know if this one occurs on b2g or also on other platforms? I added this warning recently in bug 1125325 after smaug said [1]. It seems to be happening a lot, so we should investigate. If you have a bug on file for it please cc me. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1125325#c134 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Per-test chaos mode now available, use it to help win the war on orange!
On Thursday, June 4, 2015 at 5:30:32 PM UTC-4, Chris Peterson wrote: Will chaos mode enabled tests run on Try and release branches? If a test has chaos mode enabled, then it will have chaos mode enabled on all branches, including Try and release branches. We don't know if chaos mode test failures are representative of real bugs, but could chaos mode hide bugs that only reveal themselves when users run without chaos mode? It's possible but I think this is pretty unlikely. In all of the callsites I checked, chaos mode is used to push us off the beaten path with respect to code execution flow, but it does so randomly and so in some cases we should take the same path as if chaos mode were disabled. kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Per-test chaos mode now available, use it to help win the war on orange!
On Thursday, June 4, 2015 at 6:15:35 PM UTC-4, Chris AtLee wrote: Very interesting, thank you! Would there be a way to add an environment variable or harness flag to run all tests in chaos mode? There isn't at the moment but one can definitely be added if there is a use for it. At the moment the easiest way to enable chaos mode globally is to change the value of sChaosFeatures in ChaosMode.h and recompile. kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Per-test chaos mode now available, use it to help win the war on orange!
I just landed bug 1164218 on inbound, which adds the ability to run individual mochitests and reftests in chaos mode. (For those unfamiliar with chaos mode, it's a feature added by roc a while back that makes already-random things more random; see [1] or bug 955888 for details). The idea with making it available per-test is that new tests should be written and tested locally/on try with chaos mode enabled, to flush out possible intermittent failures faster. Ideally we should also land them with chaos mode enabled. At this time we're still not certain if this will provide a lot of value (i.e. if chaos-mode-triggered failures are representative of real bugs) so it's not mandatory to make your tests run in chaos mode, but please do let me know if you try enabling it on your test and are either successful or not. We need to collect more data on the usefulness of this to see where we should take it. If it does turn out to be valuable, my hope is that we can start making pre-existing tests chaos-mode enabled as well, and eventually reduce the intermittent failure rate. See [2] for an example of how to enable chaos mode in your tests. Basically you can add chaos-mode to the reftest.list file for reftests, or call SimpleTest.testInChaosMode() for mochitests. If you do run into intermittent failures, the best way to debug them is usually to grab a recording of the failure using rr [3] and then debug the recording to see what was going on. This only works on Linux (and has some hardware requirements as well) but it's a really great tool to have. Cheers, kats [1] http://robert.ocallahan.org/2014/03/introducing-chaos-mode.html [2] https://hg.mozilla.org/integration/mozilla-inbound/rev/89ac61464a45 [3] http://rr-project.org/ or https://github.com/mozilla/rr/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: wiki page for platform-specific defines
On Wednesday, June 3, 2015 at 9:16:46 PM UTC-4, Xidorn Quan wrote: I guess it is probably better to add different color on true and false, which should improve the readability. Or probably just remove all false? Looks like Mike and Adam cleaned it to be much more readable, thanks! I also added a second table for prefs files (although I'm not sure where b2g.js is used so I left in some question marks in that one). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: wiki page for platform-specific defines
I created a new wiki page to document which platform/widget defines are true where: https://wiki.mozilla.org/Platform/Platform-specific_build_defines Please review and correct anything I got wrong, and add any additional defines as necessary. Thanks! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updated mozilla-central code coverage
Does this coverage info also include gtests? From a quick glance it looks like not. On Tuesday, May 26, 2015 at 2:59:16 PM UTC-4, Joshua Cranmer wrote: I've posted updated code coverage information for mozilla-central to https://www.tjhsst.edu/~jcranmer/m-ccov/. This data is accurate as of yesterday. For those of you who are unaware, I periodically run these code coverage statistics by use of the try server and instrumented runs. This has been made easier over the years by standardization of some of the hacks, such that you can now push to linux64-cc and get most of the same information. Notable changes I've made since the last upload: 1. I dropped debug builds, so all the information comes from Linux opt, both 32 and 64-bit. 2. Test names now derive from builder names directly, removing the need for a very long hardcoded list of M-bc means mochitest-browser-chrome. 2a. This means that what was once mochitest-1, mochitest-2, etc. is now condensed into mochitest. Mochitest-e10s-browser-chrome, etc., remain split out. 3. Minor changes in the UI frontend to help deal with the fact that my hosting webserver changed to forcing https. 4. I can now generate the ultimate combined .info file without needing manual post-processing, for the first time ever. The marionette and web-platform tests remain unaccounted for in coverage (Mn, Mn-e10s, Wr, W-* in treeherder lingo), and the new Ld (luciddream?) appears to be broken as well. On the possibility of expanding code coverage information to different platforms, languages, and tests: 1. OS X still has a link error and/or fail-to-run issue. I suspect a newer clang would help, but I lack a local OS X instance with which to do any detailed tests. I've never tested the ability of my scripts to adequately collect clang code coverage data, and I suspect they would themselves need some modification to do so. 2. Android builds work and can report back code coverage data, but so intermittently that I didn't bother to try including them. In my try run that I used to generate these results, mochitest-2 reported back data but mochitest-6 did not, yet both testsuites reported back success. The reason for this is not clear, so any help people could give in debugging issues would be most appreciated. 3. B2G desktop builds and Mulet builds on Linux appeared to work. However, the builds didn't appear to upload the gcno package for unknown reasons, and taskcluster uses such different mechanisms to upload the files that my scripts are of no use in collecting the gcda packages. 4. Windows is... special when it comes to code coverage. This is the last platform I would look at tackling. 5. JS code coverage is of course a hole I'd like to see rectified, but I don't have the time to invest in solving it myself. 6. Are we actually using Rust yet on our tryserver builds? 7. Android Java coverage is deferred until after I can get reliable Android code coverage in the first place. 8. I'd have to look into modifying mozharness to run code coverage on marionette et al builds. It shouldn't be hard, but it is annoying to have to hook into so many places to insert code coverage. 9. Ditto for Android xpcshell and cppunit tests. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag
On Thursday, April 30, 2015 at 7:22:26 PM UTC-4, Christopher Manchester wrote: You can now add --tag arguments to try syntax and they will get passed to test harnesses in your try push. Details of the implementation are in bug 978846, but if you're interested in passing other arguments from try syntax to a test harness, this can be done by adding those arguments to testing/config/mozharness/try_arguments.py. Note this is still rather coarse in the sense that arguments are forwarded without regard for whether a harness supports a particular argument, but I can imagine it being useful in a number of cases (for instance, when testing the feature with xpcshell and --tag devtools, I was able to get feedback in about ten minutes whether things were working rather than waiting for every xpcshell test to run). Can you provide a sample complete try syntax that uses this? I just did a try run with |try: -b do -p linux,macosx64,win32,win64 -u all -t none --tag apz| (after adding the apz tag to a mochitest.ini file) and it still ran all the mochitests instead of just the ones in the mochitest.ini file. Does it only work in some scenarios? Cheers, kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AsyncPanZoom enabled for one Nightly - 4/22/2015 - Windows E10S only
On Tuesday, April 21, 2015 at 10:51:58 PM UTC-4, David Anderson wrote: We're interested in any significant behavior changes with APZ, and especially any situations in which we can't pre-render content fast enough. In this case you might see blank white areas of the screen while scrolling (aka checkerboarding). Please file any sites you find this way against the paint-fast bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1154825 Also, if you see bugs that are *not* checkerboarding, please file and make them block bug 1154459. Thanks! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Ship: 3rd Party Install Tracking
On Wednesday, March 18, 2015 at 2:29:32 PM UTC-4, Mark Finkle wrote: There are good reasons for wanting to collect the data. Our marketing and growth goals for 2015 will require spending non-trivial amounts of money. The data will help us spend the money responsibly and efficiently. We still need to audit the open source SDK to see exactly what data is sent and how it's collected. We also have started doing a security/privacy/legal audit of the vendor and their collection/storage practices. These two statements to me imply that (1) we don't have a clear idea of what data we *want* in order to help us make spending decisions and consequently (2) we are free to pick a 3rd party provider which provides as-yet-unknown amounts of data, with the assumption that it will give us what we want. It seems to me that when doing something as privacy sensitive as this we should probably figure out exactly what data we want to collect *first*. Then, if and only if we can't collect it using in-house code, we should consider going with a third party service. Thoughts? kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What are your pain points when running unittests?
On Thursday, March 12, 2015 at 6:51:26 PM UTC-4, Jonathan Griffin wrote: The quintessential use case here is making it easy to reproduce a try run locally, without a local build, using a syntax something like: * runtests --try 2844bc3a9227 Ideally, this would download the appropriate build and tests.zip package, bootstrap the test environment, and run the tests using the exact same arguments as are used on try, optionally running it through an appropriate debugger. You would be able to substitute a local build and/or local tests.zip package if desired. I think this would be a *huge* help - the hardest part for me is just reproducing the stuff that happens on try. The platform I usually have the most trouble with is Fennec, because running things locally (when it works) never gives me the same results as the tryserver. There's some mention in this thread seem of getting rr recordings of stuff, and I think that would help with intermittents. However rr is limited to Linux (where it's relatively straightforward to run the same test locally) so I'm not convinced that spending resources getting rr support *at the expense of other things* is the best idea. If you have somebody sitting around with nothing to do, then great. If not, I think bringing some of the less-easy-to-work-with platforms (B2G and Fennec) up to the same level as the desktop platforms would provide better value. kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Syncing 2 scrolling operations
On Sat, Feb 28, 2015 at 3:47 AM, Paul Rouget pa...@mozilla.com wrote: How much work is that? Is it just a matter of piping things together to expose an JS method to privileged code? Not really - I think we would have to add new APIs to manipulate the layer tree of child processes from the parent process. I'm not entirely opposed to doing this but I think it would be a good idea to investigate other use cases that might impact this and design an API that is sufficiently general to handle all of those use cases. It's one of those things where even slight changes in the UX might require significant changes on the platform side, so it's worth coming up with something general enough to allow flexibility in the UX. kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Syncing 2 scrolling operations
On Thursday, February 26, 2015 at 1:06:15 PM UTC-5, Paul Rouget wrote:
I need a pretty picture to explain my problem:
http://people.mozilla.org/~prouget/scrollIssue.png
Thanks for the pretty picture! It makes it much easier to visualize the problem
:)
I tried to scroll the parent and
the child process in opposite directions. It works, but it's choppy
and not at all seamless.
This is pretty much what I would suggest, short of inventing some new API to do
this.
Any idea how I could achieve this effect in a efficient way? I was
thinking about changing (and animating) the scroll position of the
content from the main process. Maybe finding a way to make
`scrollBy{behavior: 'smooth'}` for content and parent to be synced... I
don't know. Does that make sense? If so, how to build that? If not,
any alternative way to show this toolbar?
Were you able to successfully get both things to scroll with behaviour:smooth?
Was that still choppy? If so, were you able to tell why? Was it just that one
animation started slightly before the other and so it resulted in a jittery
effect? Or did the animations actually jank while in progress?
I think if you trigger both scrolls inside a RAF and have both APZ-driven
smooth scrolling and vsync-triggered refresh driver it should be possible to
get this working, because then it will be the same layers transaction that
carries over both animations to the compositor, and they should proceed in
sync. I could be wrong though - CC'ing mason also who can provide more
information about vsync-triggered refresh driver and whether it might help in
this scenario.
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: APZC + onscroll
On Wednesday, February 25, 2015 at 10:13:20 AM UTC-5, kgu...@mozilla.com wrote: The scroll event is fired every time APZC sends a repaint request to the main thread (which is what changes the scroll position). To clarify, by changes the scroll position here I mean changes the main-thread scroll position, which is what scripts can access ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: APZC + onscroll
On Wednesday, February 25, 2015 at 2:40:12 AM UTC-5, Paul Rouget wrote: When is onscroll called if apzc is enabled? The scroll event is fired every time APZC sends a repaint request to the main thread (which is what changes the scroll position). How often? Generally this is controlled by the apz.pan_repaint_interval during panning (while the finger is down) and the apz.fling_repaint_interval during flinging (residual movement after the finger has been lifted). However we can also request repaints at other times for various reasons, and there is some code that prevents multiple repaint requests from being inflight simultaneously. Note that since the scroll event is dispatched on the main thread, any blocking main-thread operations will also impact this. So there isn't a definite answer to this but if you reduce apz.pan_repaint_interval and apz.fling_repaint_interval to around 16 that's about as fast as it's going to get. When is the first scroll event fired? Should be apz.pan_repaint_interval milliseconds after the scroll starts. Will using onscroll prevent apzc to work properly? Using onscroll doesn't slow down the APZ like touch listeners do, but if you're doing a lot of stuff in that handler it may cause the main thread to be more busy which can increase the risk of checkerboarding. Short-running listeners should have negligible impact. Cheers, kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reconciling async scrolling with onscroll handlers
On Sunday, February 15, 2015 at 4:48:06 PM UTC-5, Robert O'Callahan wrote: Their current idea is to add a new CSS property scroll-blocks-on to let a page opt into sync scrolling: https://docs.google.com/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit# In pages that drop below some performance threshold (e.g. 30fps), the browser can disable scroll-blocks-on. A more general version of the latter is to have the browser maintain a per-document mode switch that's green while the document is hitting performance targets and red when it is not, with an event firing for mode changes. In red mode, features like scroll-blocks-on would be disabled. We could potentially tie in other things here like will-change disabling. I can't say I'm a fan of this idea. For one thing, I feel like there might be a lot of cases where we rapidly switch between hitting the fps target and not, which will generate lots of spurious mode-changes events. Those events will further slow things down because more scripts will run as a result. It will also result in a very inconsistent user experience if say the parallax effect works half the time but not the other half, just based on whether some other process is hogging the CPU or not. If we do introduce a scroll-blocks-on property, then I think it should be unconditional - that is, the browser should respect it regardless of the perf implications, and it would be up to the author to make sure that perf is good. If we detect the perf is bad then we could just terminate the page entirely, or notify the user that the page is not responding, but I think adding this concept of a mode where it's not respected doesn't help anybody. I also agree with Milan that this is exposing more browser implementation detail, which I would like to avoid. kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AreWeSlimYet, now with marionette and try integration
On Thursday, February 12, 2015 at 8:58:42 PM UTC-5, Eric Rahm wrote: Over the past month or so quite a few enhancements have been made to your favorite memory regression website, https://areweslimyet.com. This is great to hear, thanks a lot for all your work on this! :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: gecko-dev and Git replication will be broken for a little while
On Friday, January 30, 2015 at 5:30:52 AM UTC-5, 陳侃如 Kan-Ru Chen wrote: I use this alias in ~/.gitconfig [alias] hg-format-patch = !sh -c 'git format-patch -kp -U8 $@|tee /dev/stderr|xargs git-patch-to-hg-patch' git Get git-patch-to-hg-patch from https://github.com/mozilla/moz-git-tools Kanru That looks pretty complicated. I use something much simpler and it's never let me down: [alias] hgp = show -M -C --binary --format=\# HG changeset patch%n# User %an %ae%n%B\ -U8 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: e10s content processes and coordinate systems
On Thursday, January 15, 2015 at 3:24:03 PM UTC-5, Handyman wrote: and the compositor... I'm not sure how it compensates but it must use a different mechanism for Compositors and CrossProcessCompositors, probably at the Layer level?). I believe this happens in RenderFrameParent::BuildLayer, with the transform getting set on the RefLayer that hosts the child process content. So the big picture is that we have introduced a new coordinate system in the content process (TabCoordinates) that are exactly like screen coordinates but located at a different origin. This could possibly be incorporated into UnitTransforms as a new space but that seems like a seriously heavy duty solution. Also, its not clear how to make that useful -- this setup seems to have been chosen so that parent and content processes can share formulas but this would mean that they would target different coordinate systems. On top of all that, the coordinate system framework doesn't seem to have been built for this sort of purpose -- it seems to be for tracking scaling, not general Euclidean operations (so it would be hard to take advantage of). Agreed, the stuff in Units.h and UnitTransforms.h was not designed for this. I agree with what roc said (and also what smaug said on the bug) - we should just fix PuppetWidget to provide the right information and use that to fix these bugs. Is there any problem you foresee with that approach? It wasn't clear to me from the bug if you had any objections to that. kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
