Re: OMTC on Windows
Hi Gijs, None of those things are true in my opinion. For what it's worth, the expected regression in CART was more around 20% than around 40%. The number surprises me a little, and we'll look into what makes CART so bad off (on our test servers) specifically. We haven't looked specifically at CART as we mostly looked into TART and Tsvgr while investigating. I'll address each point individually: a) Extremely hacky work for a 1% gain seems like a bad idea. Depending on how hacky, maintainable, etc, that seems like it might have been the wrong decision :-). But 1% gains can still accumulate, so I certainly wouldn't call them useless. b) You have to look at what the tests are meant to do, Avi knows more about the tests than I do and has already supplied some information, but there's a difference in tweaking the UI, or a specific portion of rendering, or radically changing the way we draw things. The tests might not be a good reflection of the average user experience, but they help us catch situations where we unwittingly harm performance, or where we want proof that a change in some core algorithm does indeed make things run faster. That makes them very useful, just not for radical architectural changes. Fwiw, in what CART or TART is testing I'm not claiming it will be a net performance improvement, there are however other interactions that improve that are inherently linked to this one and cannot be decoupled (because of it being an architectural change). Similarly we only run our tests on one hardware configuration, this in my mind again stresses their purpose as a relative regression test as opposed to being representative of perceived UX. c) A couple of things here, first of all we consulted with people outside of the gfx team about this, and we were in agreement with the people we talked to. When it comes to moving forward architecturally we should always be ready to accept something regressing, that has nothing to do with what team is doing the regression, that is related to what we're trying to accomplish. I can guarantee you for example, e10s will cause at least some significant regressions in some situations, yet we might very well have to accept those regressions to offer our users big improvements in other areas, as well as to pave the way for future improvements. With OMTA for example, several aspects of our (UI) performance can be improved in a way that no amount of TART improvements in the old architecture ever could. Now I don't want to repeat too much of what I've already said, but I'd like to reiterate on the fact that if there are 'real' regressions in the overall user experience, we will of course attempt to address those issues, but we are also only a pref change away from going back to on-main-thread compositing. The focus should, in my opinion be, what has actually been affected by this in a way that it has a strong, negative impact on user experience. Considering the scope of this change I am certain those things exist and they will need to be fixed. Perhaps the CART regression -is- a sign of some real unacceptable perceived performance, I'm not ruling that out, but we have not identified an interaction which significantly regressed. This is all extremely hardware dependent though (i.e. on most of my machines TART and CART both improve with OMTC), so if someone -has- seen this cause a significant performance regression in some sort of interaction, do let us know. Best regards, Bas - Original Message - From: "Gijs Kruitbosch" To: "Bas Schouten" , "Gavin Sharp" Cc: dev-tech-...@lists.mozilla.org, "mozilla.dev.platform group" , "release-drivers" Sent: Thursday, May 22, 2014 8:46:29 AM Subject: Re: OMTC on Windows Looking on from m.d.tree-management, on Fx-Team, the merge from this change caused a >40% CART regression, too, which wasn't listed in the original email. Was this unforeseeen, and if not, why was this considered acceptable? As gavin noted, considering how hard we fought for 2% improvements (one of the Australis folks said yesterday "1% was like Christmas!") despite our reasons of why things were really OK because of some of the same reasons you gave (e.g. running in ASAP mode isn't realistic, "TART is complicated", ...), this hurts - it makes it seem like (a) our (sometimes extremely hacky) work was done for no good reason, or (b) the test is fundamentally flawed and we're better off without it, or (c) when the gfx team decides it's OK to regress it, it's fine, but not when it happens to other people, quite irrespective of reasons given. All/any of those being true would give me the sad feelings. Certainly it feels to me like (b) is true if this is really meant to be a net perceived improvement despite causing a 40% performance regression in our automated tests. ~ Gijs On 18/05/2014 19:47, Bas Schouten wrote: > Hi Gavin, > > There have been several e-mails on different lists, and some communication
Re: OMTC on Windows
Looking on from m.d.tree-management, on Fx-Team, the merge from this change caused a >40% CART regression, too, which wasn't listed in the original email. Was this unforeseeen, and if not, why was this considered acceptable? As gavin noted, considering how hard we fought for 2% improvements (one of the Australis folks said yesterday "1% was like Christmas!") despite our reasons of why things were really OK because of some of the same reasons you gave (e.g. running in ASAP mode isn't realistic, "TART is complicated", ...), this hurts - it makes it seem like (a) our (sometimes extremely hacky) work was done for no good reason, or (b) the test is fundamentally flawed and we're better off without it, or (c) when the gfx team decides it's OK to regress it, it's fine, but not when it happens to other people, quite irrespective of reasons given. All/any of those being true would give me the sad feelings. Certainly it feels to me like (b) is true if this is really meant to be a net perceived improvement despite causing a 40% performance regression in our automated tests. ~ Gijs On 18/05/2014 19:47, Bas Schouten wrote: Hi Gavin, There have been several e-mails on different lists, and some communication on some bugs. Sadly the story is at this point not anywhere in a condensed form, but I will try to highlight a couple of core points, some of these will be updated further as the investigation continues. The official bug is bug 946567 but the numbers and the discussion there are far outdated (there's no 400% regression ;)): - What OMTC does to tart scores differs wildly per machine, on some machines we saw up to 10% improvements, on others up to 20% regressions. There also seems to be somewhat more of a regression on Win7 than there is on Win8. What the average is for our users is very hard to say, frankly I have no idea. - One core cause of the regression is that we're now dealing with two D3D devices when using Direct2D since we're doing D2D drawing on one thread, and D3D11 composition on the other. This means we have DXGI locking overhead to synchronize the two. This is unavoidable. - Another cause is that we're now having two surfaces in order to do double buffering, this means we need to initialize more resources when new layers come into play. This again, is unavoidable. - Yet another cause is that for some tests we composite 'ASAP' to get interesting numbers, but this causes some contention scenario's which are less likely to occur in real-life usage. Since the double buffer might copy the area validated in the last frame from the front buffer to the backbuffer in order to prevent having to redraw much more. If the compositor is compositing all the time this can block the main thread's rasterization. I have some ideas on how to improve this, but I don't know how much they'll help TART, in any case, some cost here will be unavoidable as a natural additional consequence of double buffering. - The TART number story is complicated, sometimes it's hard to know what exactly they do, and don't measure (which might be different with and without OMTC) and how that affects practical performance. I've been told this by Avi and it matches my practical experience with the numbers. I don't know the exact reasons and Avi is probably a better person to talk about this than I am :-). These are the core reasons that we were able to identify from profiling. Other than that the things I said in my previous e-mail still apply. We believe we're offering significant UX improvements with async video and are enabling more significant improvements in the future. Once we've fixed the obvious problems we will continue to see if there's something that can be done, either through tiling or through other improvements, particularly in the last point I mentioned there might be some, not 'too' complex things we can do to offer some small improvement. If we want to have a more detailed discussion we should probably pick a list to have this on and try not to spam people too much :-). Bas - Original Message - From: "Gavin Sharp" To: "Bas Schouten" Cc: "dev-tree-management" , dev-tech-...@lists.mozilla.org, "release-drivers" , "mozilla.dev.platform group" Sent: Sunday, May 18, 2014 6:23:58 PM Subject: Re: OMTC on Windows but tart will regress by ~20%, and several other suites will regress as well. We've investigated this extensively and we believe the majority of these regressions are due to the nature of OMTC and the fact that we have to do more work. Where can I read more about the TART investigations? I'd like to understand why it is seen as inevitable, and get some of the details of the regression. OMTC is important, and I'm excited to see it land on Windows, but the Firefox and Performance teams have just come off a months-long effort to make significant wins in TART, and the thought of taking a 20% regression (huge compared to some of the improvements we fought for
Re: OMTC on Windows
On 2014-05-22, 5:18 AM, Bas Schouten wrote: Hi Gijs, None of those things are true in my opinion. For what it's worth, the expected regression in CART was more around 20% than around 40%. The number surprises me a little, and we'll look into what makes CART so bad off (on our test servers) specifically. We haven't looked specifically at CART as we mostly looked into TART and Tsvgr while investigating. I'll address each point individually: a) Extremely hacky work for a 1% gain seems like a bad idea. Depending on how hacky, maintainable, etc, that seems like it might have been the wrong decision :-). But 1% gains can still accumulate, so I certainly wouldn't call them useless. b) You have to look at what the tests are meant to do, Avi knows more about the tests than I do and has already supplied some information, but there's a difference in tweaking the UI, or a specific portion of rendering, or radically changing the way we draw things. The tests might not be a good reflection of the average user experience, but they help us catch situations where we unwittingly harm performance, or where we want proof that a change in some core algorithm does indeed make things run faster. That makes them very useful, just not for radical architectural changes. Fwiw, in what CART or TART is testing I'm not claiming it will be a net performance improvement, there are however other interactions that improve that are inherently linked to this one and cannot be decoupled (because of it being an architectural change). Similarly we only run our tests on one hardware configuration, this in my mind again stresses their purpose as a relative regression test as opposed t o being representative of perceived UX. c) A couple of things here, first of all we consulted with people outside of the gfx team about this, and we were in agreement with the people we talked to. When it comes to moving forward architecturally we should always be ready to accept something regressing, that has nothing to do with what team is doing the regression, that is related to what we're trying to accomplish. I can guarantee you for example, e10s will cause at least some significant regressions in some situations, yet we might very well have to accept those regressions to offer our users big improvements in other areas, as well as to pave the way for future improvements. With OMTA for example, several aspects of our (UI) performance can be improved in a way that no amount of TART improvements in the old architecture ever could. Now I don't want to repeat too much of what I've already said, but I'd like to reiterate on the fact that if there are 'real' regressions in the overall user experience, we will of course attempt to address those issues, but we are also only a pref change away from going back to on-main-thread compositing. The focus should, in my opinion be, what has actually been affected by this in a way that it has a strong, negative impact on user experience. Considering the scope of this change I am certain those things exist and they will need to be fixed. Perhaps the CART regression -is- a sign of some real unacceptable perceived performance, I'm not ruling that out, but we have not identified an interaction which significantly regressed. This is all extremely hardware dependent though (i.e. on most of my machines TART and CART both improve with OMTC), so if someone -has- seen this cause a significant performance regression in some sort of interaction, do let us know. Have you tried to test those interactions on the same Talos machines that the CART regressions happened on? I think that would definitively answer the question of whether these regressions affect an interaction we care about. (Also, out of curiosity, what is the list of those interactions?) Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
error running mochitest-browser
Hi All, I'm facing an error when downloading the latest code from mercurial, doing a build and then trying to run the mochitest-browser tests. I face the following error about 6 minutes into the test run. console.error: 6:30.14 [CustomizableUI] 6:30.14 TypeError: realNode is null -- chrome://browser/content/customizableui/toolbar.xml:184 Again, I haven't made any changes to the code base. I did not see anything in Bugzilla like this and before I post anything there was curious if anyone had seen anything like this -- maybe a configuration problem? The ./mach build did succeed. Thanks, -tamara ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: error running mochitest-browser
Some questions: What platform is this on? How are you invoking the test suite? Which test is running when this error happens? Are you using mozilla-central, fx-team, mozilla-inbound, ...? Can you paste a copy of your .mozconfig configuration? ~ Gijs On 22/05/2014 14:40, thills wrote: Hi All, I'm facing an error when downloading the latest code from mercurial, doing a build and then trying to run the mochitest-browser tests. I face the following error about 6 minutes into the test run. console.error: 6:30.14 [CustomizableUI] 6:30.14 TypeError: realNode is null -- chrome://browser/content/customizableui/toolbar.xml:184 Again, I haven't made any changes to the code base. I did not see anything in Bugzilla like this and before I post anything there was curious if anyone had seen anything like this -- maybe a configuration problem? The ./mach build did succeed. Thanks, -tamara ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [DEPRECATED] Apple OSX QTkit API dependencies
On May 21, 2014, at 4:52 PM, Mike Hommey wrote: > On Wed, May 21, 2014 at 10:22:44PM +0200, Emmanuel Engelhart wrote: >> On 21.05.2014 21:59, Ralph Giles wrote: >>> On 2014-05-21 9:56 AM, Emmanuel Engelhart wrote: >>> checker. But it seems the Mozilla codes uses this API for many things linked to video stuff: https://mxr.mozilla.org/mozilla-central/search?find=%2F&string=QTKit >>> >>> This is all video capture code for WebRTC. What API does Apple recommend >>> instead? >>> >>> It's also worth reporting this upstream at webrtc.org, since that >>> codebase *is* used in a number of iOS applications. >> >> More Details are given about the deprecated API in 10.9 here (see >> "Deprecated Frameworks" paragraph) >> https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_9.html >> >> Extract "The QuickTime and QTKit frameworks are superseded by AV Kit and AV >> Foundation." >> >> More information about transitioning code: >> https://developer.apple.com/library/mac/technotes/tn2300/_index.html#//apple_ref/doc/uid/DTS40012852 > > "Introduced in OS X 10.7" > > You can't make a 10.6-compatible build with this. > > Mike You can, but you have to use the SDK feature correctly, and you have to leave in code that detects whether or not the new API is available, and fall back on the old API if it is not. It's tricky. Syd Polk sp...@mozilla.com +1-512-905-9904 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OMTC on Windows
- Original Message - > From: "Ehsan Akhgari" > To: "Bas Schouten" , "Gijs Kruitbosch" > > Cc: "Gavin Sharp" , dev-tech-...@lists.mozilla.org, > "mozilla.dev.platform group" > , "release-drivers" > > Sent: Thursday, May 22, 2014 12:56:26 PM > Subject: Re: OMTC on Windows > > On 2014-05-22, 5:18 AM, Bas Schouten wrote: > > The focus should, in my opinion be, what has actually been affected by this > > in a way that it has a strong, negative impact on user experience. > > Considering the scope of this change I am certain those things exist and > > they will need to be fixed. Perhaps the CART regression -is- a sign of > > some real unacceptable perceived performance, I'm not ruling that out, but > > we have not identified an interaction which significantly regressed. This > > is all extremely hardware dependent though (i.e. on most of my machines > > TART and CART both improve with OMTC), so if someone -has- seen this cause > > a significant performance regression in some sort of interaction, do let > > us know. > > Have you tried to test those interactions on the same Talos machines > that the CART regressions happened on? I think that would definitively > answer the question of whether these regressions affect an interaction > we care about. > > (Also, out of curiosity, what is the list of those interactions?) > > Cheers, > Ehsan We have, but it should be noted CART does some special things I believe to draw 'as fast as possible', so even a 40% regression, could still be 'fast enough' and we still wouldn't see an affect we cared about. As I said, I didn't look at CART specifically but more at TART. One interaction that was particularly bad there in the numbers, was 'tab-close' that looked fine to me on the machines I looked at, but it probably deserves some specific attention on some other, slower machines. Thanks! Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OMTC on Windows
I don't know if everyone is noticing this or not, but I am noticing a lot of misplaced paint blocks while scrolling/animation etc. Sometimes even the complete tab won't refresh on a tab change. On Thu, May 22, 2014 at 8:26 PM, Bas Schouten wrote: > > > > > - Original Message - > > From: "Ehsan Akhgari" > > To: "Bas Schouten" , "Gijs Kruitbosch" < > gijskruitbo...@gmail.com> > > Cc: "Gavin Sharp" , dev-tech-...@lists.mozilla.org, > "mozilla.dev.platform group" > > , "release-drivers" < > release-driv...@mozilla.org> > > Sent: Thursday, May 22, 2014 12:56:26 PM > > Subject: Re: OMTC on Windows > > > > On 2014-05-22, 5:18 AM, Bas Schouten wrote: > > > The focus should, in my opinion be, what has actually been affected by > this > > > in a way that it has a strong, negative impact on user experience. > > > Considering the scope of this change I am certain those things exist > and > > > they will need to be fixed. Perhaps the CART regression -is- a sign of > > > some real unacceptable perceived performance, I'm not ruling that out, > but > > > we have not identified an interaction which significantly regressed. > This > > > is all extremely hardware dependent though (i.e. on most of my machines > > > TART and CART both improve with OMTC), so if someone -has- seen this > cause > > > a significant performance regression in some sort of interaction, do > let > > > us know. > > > > Have you tried to test those interactions on the same Talos machines > > that the CART regressions happened on? I think that would definitively > > answer the question of whether these regressions affect an interaction > > we care about. > > > > (Also, out of curiosity, what is the list of those interactions?) > > > > Cheers, > > Ehsan > > We have, but it should be noted CART does some special things I believe to > draw 'as fast as possible', so even a 40% regression, could still be 'fast > enough' and we still wouldn't see an affect we cared about. > > As I said, I didn't look at CART specifically but more at TART. One > interaction that was particularly bad there in the numbers, was 'tab-close' > that looked fine to me on the machines I looked at, but it probably > deserves some specific attention on some other, slower machines. > > Thanks! > > Bas > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Girish Sharma B.Tech(H), Civil Engineering, Indian Institute of Technology, Kharagpur ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OMTC on Windows
Hi Girish, This sounds like bug 1012213. We're aware of this bug and are working on it! Best regards, Bas - Original Message - From: "Girish Sharma" To: "Bas Schouten" , "mozilla.dev.platform group" , dev-tech-...@lists.mozilla.org, "release-drivers" Sent: Thursday, May 22, 2014 8:15:18 PM Subject: Re: OMTC on Windows I don't know if everyone is noticing this or not, but I am noticing a lot of misplaced paint blocks while scrolling/animation etc. Sometimes even the complete tab won't refresh on a tab change. On Thu, May 22, 2014 at 8:26 PM, Bas Schouten wrote: > > > > > - Original Message - > > From: "Ehsan Akhgari" > > To: "Bas Schouten" , "Gijs Kruitbosch" < > gijskruitbo...@gmail.com> > > Cc: "Gavin Sharp" , dev-tech-...@lists.mozilla.org, > "mozilla.dev.platform group" > > , "release-drivers" < > release-driv...@mozilla.org> > > Sent: Thursday, May 22, 2014 12:56:26 PM > > Subject: Re: OMTC on Windows > > > > On 2014-05-22, 5:18 AM, Bas Schouten wrote: > > > The focus should, in my opinion be, what has actually been affected by > this > > > in a way that it has a strong, negative impact on user experience. > > > Considering the scope of this change I am certain those things exist > and > > > they will need to be fixed. Perhaps the CART regression -is- a sign of > > > some real unacceptable perceived performance, I'm not ruling that out, > but > > > we have not identified an interaction which significantly regressed. > This > > > is all extremely hardware dependent though (i.e. on most of my machines > > > TART and CART both improve with OMTC), so if someone -has- seen this > cause > > > a significant performance regression in some sort of interaction, do > let > > > us know. > > > > Have you tried to test those interactions on the same Talos machines > > that the CART regressions happened on? I think that would definitively > > answer the question of whether these regressions affect an interaction > > we care about. > > > > (Also, out of curiosity, what is the list of those interactions?) > > > > Cheers, > > Ehsan > > We have, but it should be noted CART does some special things I believe to > draw 'as fast as possible', so even a 40% regression, could still be 'fast > enough' and we still wouldn't see an affect we cared about. > > As I said, I didn't look at CART specifically but more at TART. One > interaction that was particularly bad there in the numbers, was 'tab-close' > that looked fine to me on the machines I looked at, but it probably > deserves some specific attention on some other, slower machines. > > Thanks! > > Bas > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Girish Sharma B.Tech(H), Civil Engineering, Indian Institute of Technology, Kharagpur ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OMTC on Windows
On Fri, May 23, 2014 at 1:51 AM, Bas Schouten wrote: > bug 1012213 Yup, looks like that only. Thanks for the bug. -- Girish Sharma B.Tech(H), Civil Engineering, Indian Institute of Technology, Kharagpur ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: CSSOM-View scroll-behavior property
Summary: CSSOM-View defines a new css property, 'scroll-behavior'. When set to 'smooth', scrolling boxes will be scrolled in a smooth fashion using a user-agent-defined function. Implementing this property will enable more fluid scrolling interfaces consistent with modern UI paradigms without needing to update the position manually on a frame-by-frame basis in Javascript. In much the same way as APZ's fling gestures, the fluid scrolling will take over the scroll position updates when CSSOM methods or navigation set the scroll position. Other effects such as smooth-scroll-snapping can be built upon this property by setting the scroll position for a smooth scrolling box at the end of a dragging event. This is beneficial to applications such as the B2G home screen and image carousels. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1010538 Link to standard: http://dev.w3.org/csswg/cssom-view/#smooth-scrolling:-the-%27scroll-behavior%27-property Platform coverage: Android, Desktop, Firefox OS This functionality is beneficial on all platforms. The implementation fits naturally within the APZ classes; however, APZ may not be available for some time outside of B2G. I would like to gauge the demand for this functionality outside of B2G to determine if it should be implemented independently of APZ and land earlier on other platforms. Estimated or target release: TBD Preference behind which this will be implemented: layout.css.scroll-behavior.enabled ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Follow up on clang-format
Some of you may remember the discussion on clang-format and the `mach clang-format` command. What we have in place right now is very temporary but it is functional enough to give it a try. I have not put the effort into upstreaming my changes. Depending on the feedback I receive I will either: * Finish my existing changes and upstream them * Remove the `mach clang-format` command altogether * Do nothing I have personally found it useful. However I would like to hear from other people who have tried it to help me decide what to do next. Anthony ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G emulator issues
On Tuesday, April 8, 2014 11:45:15 PM UTC+8, Mike Habicher wrote: > In my experience running tests locally, a single mochitest run on the > ARM emulator (hardware: Thinkpad X220, 16GB RAM, SSD) where everything > was built with 'B2G_DEBUG=0 B2G_NOOPT=0' will run in 2 to 3 minutes. The > same test, run with 'B2G_DEBUG=1 B2G_NOOPT=0' will take 7 to 10 minutes. > --m. It could be the same problem as Bug 1012516. test_media_selection.html can take up to 1025454ms on B2G ICS Emulator Debug. MediaManager will GC after finishing each token and this test has 90 tokens. It takes 10s * 90 = 900s in GC. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
