Re: OMTC on Windows
Hi Gavin, I initially responded to Gijs' e-mail a while ago, before it got through dev-platform moderation. Since then I've discovered one bug which I believe is related. This one is tracked in bug 1017298. In particular this occurs when a user first has more tabs open than the window can fit, i.e. the tab strip becomes 'scrollable', and then starts closing them, without interruption, to the point where they do fit, and they start 'growing'. This causes layers to rapidly change size (every animation frame), since the tab strip in this scenario 'remains actively layerized' for a little while (unlike when it was never overflowing in the first place, and therefor never got layerized). There are reasons to belief the new architecture performs somewhat worse than the old architecture when resizing layers. Usually this is a rare situation but I believe the situation described above -might- be exactly what happens during the TART tab close tests. In general I don't think many users will run into this, but it might explain part of that. Matt is looking into whether something can be done here. I'll continue looking into what might affect our performance numbers. If either people from the performance teams or the desktop teams are interested in investigating our tests and how well they measure practical performance, I think that would be very valuable, and it would help us a lot in identifying for what sort of interactions we need to investigate the performance. In addition to that if the performance or desktop teams have good ideas of other interactions (than tab-close) which seem to have regressed a lot in particular, that will also help a lot in our investigations. My knowledge of TART is limited. Bug 1013262 is the general tracking bug but there's not too much info there to be honest. Thanks! Bas - Original Message - From: Gavin Sharp ga...@gavinsharp.com To: Vladimir Vukicevic vladi...@mozilla.com Cc: Gijs Kruitbosch gijskruitbo...@gmail.com, Bas Schouten bschou...@mozilla.com, dev-tech-...@lists.mozilla.org, mozilla.dev.platform group dev-platform@lists.mozilla.org, release-drivers release-driv...@mozilla.org Sent: Wednesday, May 28, 2014 7:15:09 PM Subject: Re: OMTC on Windows Who's responsible for looking into the test/regression? Bas? Does the person looking into it need help from the performance or desktop teams? What bug is tracking that work? Gavin On Wed, May 28, 2014 at 12:12 PM, Vladimir Vukicevic vladi...@mozilla.comwrote: (Note: I have not looked into the details of CART/TART and their interaction with OMTC) It's entirely possible that (b) is true *now* -- the test may have been good and proper for the previous environment, but now the environment characteristics were changed such that the test needs tweaks. Empirically, I have not seen any regressions on any of my Windows machines (which is basically all of them); things like tab animations and the like have started feeling smoother even after a long-running browser session with many tabs. I realize this is not the same as cold hard numbers, but it does suggest to me that we need to take another look at the tests now. - Vlad - Original Message - From: Gijs Kruitbosch gijskruitbo...@gmail.com To: Bas Schouten bschou...@mozilla.com, Gavin Sharp ga...@gavinsharp.com Cc: dev-tech-...@lists.mozilla.org, mozilla.dev.platform group dev-platform@lists.mozilla.org, release-drivers release-driv...@mozilla.org Sent: Thursday, May 22, 2014 4: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 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
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 gijskruitbo...@gmail.com To: Bas Schouten bschou...@mozilla.com, Gavin Sharp ga...@gavinsharp.com Cc: dev-tech-...@lists.mozilla.org, mozilla.dev.platform group dev-platform@lists.mozilla.org, release-drivers release-driv...@mozilla.org 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
Re: OMTC on Windows
- Original Message - From: Ehsan Akhgari ehsan.akhg...@gmail.com To: Bas Schouten bschou...@mozilla.com, Gijs Kruitbosch gijskruitbo...@gmail.com Cc: Gavin Sharp ga...@gavinsharp.com, dev-tech-...@lists.mozilla.org, mozilla.dev.platform group dev-platform@lists.mozilla.org, 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
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 scrapmachi...@gmail.com To: Bas Schouten bschou...@mozilla.com, mozilla.dev.platform group dev-platform@lists.mozilla.org, dev-tech-...@lists.mozilla.org, release-drivers release-driv...@mozilla.org 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 bschou...@mozilla.com wrote: - Original Message - From: Ehsan Akhgari ehsan.akhg...@gmail.com To: Bas Schouten bschou...@mozilla.com, Gijs Kruitbosch gijskruitbo...@gmail.com Cc: Gavin Sharp ga...@gavinsharp.com, dev-tech-...@lists.mozilla.org, mozilla.dev.platform group dev-platform@lists.mozilla.org, 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
OMTC on Windows
Hey all, After quite a lot of waiting we've switched on OMTC on Windows by default today (bug 899785). This is a great move towards moving all our platforms onto OMTC (only linux is left now), and will allow us to remove a lot of code that we've currently been duplicating. Furthermore it puts us on track for enabling other features on desktop like APZ, off main thread animations and other improvements. Having said that we realize that what we've currently landed and turned on is not completely bug free. There's several bugs still open (some more serious than others) which we will be addressing in the coming weeks, hopefully before the merge to Aurora. The main reason we've switched it on now is that we want to get as much data as possible from the nightly channel and our nightly user base before the aurora merge, as well as wanting to prevent any new regressions from creeping in while we fix the remaining problems. This was extensively discussed both internally in the graphics team and externally with other people and we believe we're at a point now where things are sufficiently stabilized for our nightly audience. OMTC is enabled and disabled with a single pref so if unforeseen, serious consequences occur we can disable it quickly at any stage. We will inevitably find new bugs in the coming weeks, please link any bugs you happen to come across to bug 899785, if anything se ems very serious, please let us know, we'll attempt to come up with a solution on the short-term rather than disabling OMTC and reducing the amount of feedback we get. There's also some important notes to make on performance, which we expect to be reported by our automated systems: - Bug 1000640 is about WebGL. Currently OMTC regresses WebGL performance considerably, patches to fix this are underway and this should be fixed on the very short term. - Several of the Talos test suite numbers will change considerably (especially with Direct2D enabled), this means Tscroll for example will improve by ~25%, 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. We see no value in holding off OMTC because of these regressions as we'll have to go there anyway. Once the last correctness and stability problems are all solved we will go back to trying to find ways to get back some of the performance regressions. We're also planning to move to a system more like tiling in desktop, which will change the performance characteristics significantly again, so we don't want to sink too much time into optimizing the current situation. - Memory numbers will increase somewhat, this is unavoidable, there's several steps which have to be taken when doing off main thread compositing (like double-buffering), which inherently use more memory. - On a brighter note: Async video is also enabled by these patches. This means that when the main thread is busy churning JavaScript, instead of stuttering your video should now happily continue playing! - Also there's some indications that there's a subjective increase in scrolling performance as well. If you have any questions please feel free to reach out to myself or other members of the graphics team! Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OMTC on Windows
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 ga...@gavinsharp.com To: Bas Schouten bschou...@mozilla.com Cc: dev-tree-management dev-tree-managem...@lists.mozilla.org, dev-tech-...@lists.mozilla.org, release-drivers release-driv...@mozilla.org, mozilla.dev.platform group dev-platform@lists.mozilla.org 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) is pretty disheartening. Gavin On Sun, May 18, 2014 at 12:16 AM, Bas Schouten bschou...@mozilla.com wrote: Hey all, After quite a lot of waiting we've switched on OMTC on Windows by default today (bug 899785). This is a great move towards moving all our platforms onto OMTC (only linux is left now), and will allow us to remove a lot of code that we've currently been duplicating. Furthermore it puts us on track for enabling other features on desktop like APZ, off main thread animations and other improvements. Having said that we realize that what we've currently landed and turned on is not completely bug free. There's several bugs still open (some more serious than others) which we will be addressing in the coming weeks, hopefully before the merge to Aurora. The main reason we've switched it on now is that we want to get as much data as possible from the nightly channel and our nightly user base before the aurora merge, as well as wanting to prevent any new regressions from
Re: OMTC on Windows
Hi Armen, You -could- be seeing all kinds of bugs, but the most likely things I'd be expecting is things while window shapes and such are updating (i.e. resizing, pop-up windows, awesomebar, etc.) particularly since those type of short-lived compositors are not typical on mobile devices where we've been using OMTC for the longest, as well as being very platform-specific in their behavior. Thanks! Bas - Original Message - From: Armen Zambrano G. arme...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Sunday, May 18, 2014 5:50:50 PM Subject: Re: OMTC on Windows What kind of bugs could we expect seeing? Any place you would like us to put focus on testing? Thanks for all the hard work to get this in. cheers, Armen On 2014-05-18, 3:16 AM, Bas Schouten wrote: Hey all, After quite a lot of waiting we've switched on OMTC on Windows by default today (bug 899785). This is a great move towards moving all our platforms onto OMTC (only linux is left now), and will allow us to remove a lot of code that we've currently been duplicating. Furthermore it puts us on track for enabling other features on desktop like APZ, off main thread animations and other improvements. Having said that we realize that what we've currently landed and turned on is not completely bug free. There's several bugs still open (some more serious than others) which we will be addressing in the coming weeks, hopefully before the merge to Aurora. The main reason we've switched it on now is that we want to get as much data as possible from the nightly channel and our nightly user base before the aurora merge, as well as wanting to prevent any new regressions from creeping in while we fix the remaining problems. This was extensively discussed both internally in the graphics team and externally with other people and we believe we're at a point now where things are sufficiently stabilized for our nightly audience. OMTC is enabled and disabled with a single pref so if unforeseen, serious consequences occur we can disable it quickly at any stage. We will inevitably find new bugs in the coming weeks, please link any bugs you happen to come across to bug 899785, if anything seems ver y serious, please let us know, we'll attempt to come up with a solution on the short-term rather than disabling OMTC and reducing the amount of feedback we get. There's also some important notes to make on performance, which we expect to be reported by our automated systems: - Bug 1000640 is about WebGL. Currently OMTC regresses WebGL performance considerably, patches to fix this are underway and this should be fixed on the very short term. - Several of the Talos test suite numbers will change considerably (especially with Direct2D enabled), this means Tscroll for example will improve by ~25%, 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. We see no value in holding off OMTC because of these regressions as we'll have to go there anyway. Once the last correctness and stability problems are all solved we will go back to trying to find ways to get back some of the performance regressions. We're also planning to move to a system more like tiling in desktop, which will change the performance characteristics significantly again, so we don't want to sink too much time into optimizing the current situation. - Memory numbers will increase somewhat, this is unavoidable, there's several steps which have to be taken when doing off main thread compositing (like double-buffering), which inherently use more memory. - On a brighter note: Async video is also enabled by these patches. This means that when the main thread is busy churning JavaScript, instead of stuttering your video should now happily continue playing! - Also there's some indications that there's a subjective increase in scrolling performance as well. If you have any questions please feel free to reach out to myself or other members of the graphics team! Bas -- Zambrano Gasparnian, Armen (armenzg) Mozilla Senior Release Engineer https://mozillians.org/en-US/u/armenzg/ http://armenzg.blogspot.ca ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reacting more strongly to low-memory situations in Firefox 25
- Original Message - From: Bas Schouten bschou...@mozilla.com To: dev-platform@lists.mozilla.org Cc: David Major dma...@mozilla.com, Nathan Froyd froy...@mozilla.com, Firefox Dev firefox-...@mozilla.org Sent: Tuesday, November 26, 2013 1:15:44 AM Subject: Re: Reacting more strongly to low-memory situations in Firefox 25 - Original Message - From: Benjamin Smedberg benja...@smedbergs.us To: dev-platform@lists.mozilla.org, Bas Schouten bschou...@mozilla.com, David Major dma...@mozilla.com, Nathan Froyd froy...@mozilla.com, Firefox Dev firefox-...@mozilla.org Sent: Monday, November 25, 2013 5:02:50 PM Subject: Reacting more strongly to low-memory situations in Firefox 25 ... == Graphics Solutions == The issues reported in bug 930797 at least appear to be related to HTML5 video rendering. The STR aren't precise, but it seems that we should try and understand and fix the issue reported by that user. Disabling hardware acceleration does not appear to help. ... For what it's worth, just to add some info to this, in my own experience on my machines in most cases Firefox seems to climb to about 1.1-1.3 GB of memory usage fairly quickly (i.e. 2 days of keeping it open), and sort of stabilize around that number. Usually when I do an about memory in this case my memory reports about 500 MB+ in JS, a surprising amount (150 MB) in VRAM usage for DrawTargets (this would be in our address space on the affected intel machines), we should investigate the latter. This is usually with about 20 tabs open. I've filed a bug for the latter part of this (the higher than expected DrawTarget memory usage), bug 944562. I'll look into it there. Although I don't think the number's high enough to cause a lot of trouble. I don't understand it and would like to. Best regards, Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reacting more strongly to low-memory situations in Firefox 25
- Original Message - From: Benjamin Smedberg benja...@smedbergs.us To: dev-platform@lists.mozilla.org, Bas Schouten bschou...@mozilla.com, David Major dma...@mozilla.com, Nathan Froyd froy...@mozilla.com, Firefox Dev firefox-...@mozilla.org Sent: Monday, November 25, 2013 5:02:50 PM Subject: Reacting more strongly to low-memory situations in Firefox 25 Unfortunately, often when we are out of memory crash reports come back as empty minidumps (because the crash reporter has to allocation memory and/or VM space to create minidumps). We believe that most of the empty-minidump crashes present on crash-stats are in fact also out-of-memory crashes. I've been creating reports about OOM crashes using crash-stats and found some startling data: Looking just at the Windows crashes from last Friday (22-Nov): * probably not OOM: 91565 * probably OOM: 57841 * unknown (not enough data because they are running an old version of Windows that doesn't report VM information in crash reports): 150874 The criterion for probably OOM are: * Has an OOMAnnotationSize marking meaning jemalloc aborted an infallible allocator * Has ABORT: OOM in the app notes meaning XPCOM aborted in infallible string/hashtable/array code * Has 50MB of contiguous free VM space This data seems to indicate that almost 40% of our Firefox crashes are due to OOM conditions. Because one of the long-term possibilities discussed for solving this issue is releasing a 64-bit version of Firefox, I additionally broke down the OOM crashes into users running a 32-bit version of Windows and users running a 64-bit version of Windows: OOM,win64,15744 OOM,win32,42097 I did this by checking the TotalVirtualMemory annotation in the crash report: if it reports 4G of TotalVirtualMemory, then the user has a 64-bit Windows, and if it reports either 2G or 3G, the user is running a 32-bit Windows. So I do not expect that doing Firefox for win64 will help users who are already experiencing memory issues, although it may well help new users and users who are running memory-intensive applications such as games. I'm a little confused, when I force OOM my firefox build on 64-bit windows it -definitely- goes down before it reaches more than 3GB of working set. Am I missing something here? Scripts for this analysis at https://github.com/mozilla/jydoop/blob/master/scripts/oom-classifier.py if you want to see what it's doing. = Next Steps = As far as I can tell, there are several basic problems that we should be tackling. For now, I'm going to brainstorm some ideas and hope that people will react or take of these items. ... == Graphics Solutions == The issues reported in bug 930797 at least appear to be related to HTML5 video rendering. The STR aren't precise, but it seems that we should try and understand and fix the issue reported by that user. Disabling hardware acceleration does not appear to help. Bas has a bunch of information in bug 859955 about degenerate behavior of graphics drivers: they often map textures into the Firefox process, and sometimes cache the latest N textures (N=200 in one test) no matter what the texture size is. I have a feeling that we need to do something here, but it's not clear what. Perhaps it's driver-specific workarounds, or blacklisting old driver versions, or working with driver vendors to have better behavior. I should highlight something here, caching the last N textures is only occurring in drivers which do -not- map into your address space as far as I have see in my testing. Intel stock drivers seem to map into your address space, but do -not- seem to do any caching. The most likely cause of the OOM here is simply that currently, we keep both the texture, and a RAM copy around of any image in our image cache that has been drawn. This means for users using Direct2D with these drivers an image will use twice as much address space as for users using software rendering. We should probably alter imagelib to discard the RAM copy when having hardware acceleration, and in that case actual address space usage should be the same for users with, and without hardware acceleration. For what it's worth, just to add some info to this, in my own experience on my machines in most cases Firefox seems to climb to about 1.1-1.3 GB of memory usage fairly quickly (i.e. 2 days of keeping it open), and sort of stabilize around that number. Usually when I do an about memory in this case my memory reports about 500 MB+ in JS, a surprising amount (150 MB) in VRAM usage for DrawTargets (this would be in our address space on the affected intel machines), we should investigate the latter. This is usually with about 20 tabs open. Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: vsync proposal
- Original Message - From: Robert O'Callahan rob...@ocallahan.org To: Bas Schouten bschou...@mozilla.com Cc: Jeff Muizelaar jmuizel...@mozilla.com, dev-platform@lists.mozilla.org, Vladimir Vukicevic vladi...@mozilla.com, avih...@yahoo.com Sent: Wednesday, August 14, 2013 9:36:15 PM Subject: Re: vsync proposal On Wed, Aug 14, 2013 at 9:39 PM, Bas Schouten bschou...@mozilla.com wrote: From: Robert O'Callahan rob...@ocallahan.org That would be good in some ways, but it doesn't handle off-main-thread animation when the main thread's drawing is late (e.g. because the main thread is stuck doing something else). For that we must have a way to control composition based on VBlank signals that doesn't involve the main thread. Right, I'm saying you dispatch the VBlank events to any thread that needs to do things on VBlank, so you might -also- dispatch it to any thread that controls async animations (even if this is the compositor thread), I simply wouldn't put this 'in between' the VBlank event and the main thread. OK. Depending on what your exact proposal is, that could cause races between layer-tree updates triggered by main-thread requestAnimationFrame triggered by a VBlank event, and other compositor-thread activity triggered by the same VBlank event. This can relatively easily solved if we want to, but it does indeed require a little more care. Nor do I really think in general where we tick the refreshdriver should be affected here. I think we simply want this low-latency composition to be directly event driven (i.e. user-input). Simply repainting and recompositing in response to every input event can easily lead to overpainting, especially if you include mouse movement. Possibly, you could limit this to some extent, or more importantly when a user is actively giving input which affect the layer tree (panning/zooming) it might be okay to overdraw and consume a little more power and that might actually be what you want in order to optimize the user experience by minimizing latency. I'm not sure that's true, but it could very well be. I also think the 'vblank event handler' should be completely left out of of this, except maybe to schedule the timing for the composition (since this composition will be driven by other events). I'm not sure I understand you correctly. Can you please produce a detailed proposal? I'm off today but I'll try my best to have something more concrete by the beginning of next week. Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: vsync proposal
- Original Message - From: Robert O'Callahan rob...@ocallahan.org To: Bas Schouten bschou...@mozilla.com Cc: Jeff Muizelaar jmuizel...@mozilla.com, dev-platform@lists.mozilla.org, Vladimir Vukicevic vladi...@mozilla.com, avih...@yahoo.com Sent: Wednesday, August 14, 2013 1:25:03 AM Subject: Re: vsync proposal On Wed, Aug 14, 2013 at 12:13 PM, Bas Schouten bschou...@mozilla.comwrote: Since you want composition to occur whenever drawing has occurred, I don't really think it should really be what's working on doing any processing for the vblank event. The VBlank event should just fire, indiscriminately whenever VBlank occurs. I believe we should then consume that event on whatever thread is actually doing drawing which might want to know about this (a user input thread? the main thread?) and these should then decide when to do their drawing and if that warrants a new composition. That way you could have, just after vblank, all your scheduled drawing be done, and a composition scheduled. But then if right before the next vblank a panning/zooming event comes in you can still process that and present a new frame to minimize latency (if desired). That would be good in some ways, but it doesn't handle off-main-thread animation when the main thread's drawing is late (e.g. because the main thread is stuck doing something else). For that we must have a way to control composition based on VBlank signals that doesn't involve the main thread. Right, I'm saying you dispatch the VBlank events to any thread that needs to do things on VBlank, so you might -also- dispatch it to any thread that controls async animations (even if this is the compositor thread), I simply wouldn't put this 'in between' the VBlank event and the main thread. What you could also do is do all your main thread drawing and processing rAF things just after vblank, since they'll likely be somewhat time consuming, and schedule your composition only for example 5 ms before VBlank (since that will likely be fast). You could then make some adjustments to the layer tree through the APZC for user input later in the frame, and still have those taken into account for composition, that would give you a minimal input latency without wasted work and still starting the content drawing required as early as possible giving it maximum opportunity to make the next frame. This may be a little bit too complicated for a first implementation, but I wanted to throw it out there as a suggestion as well. That sounds exactly like the Lowering Latency extension in the wiki page (if we treat everything as a low latency window). If you agree, maybe we should just do this. Not completely, first of all I don't think as suggested in the proposal this should be done on a per-window basis. Nor do I really think in general where we tick the refreshdriver should be affected here. I think we simply want this low-latency composition to be directly event driven (i.e. user-input). I also think the 'vblank event handler' should be completely left out of of this, except maybe to schedule the timing for the composition (since this composition will be driven by other events). Best regards, Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: vsync proposal
- Original Message - From: Robert O'Callahan rob...@ocallahan.org To: Jeff Muizelaar jmuizel...@mozilla.com Cc: dev-platform@lists.mozilla.org, Vladimir Vukicevic vladi...@mozilla.com, avih...@yahoo.com, Bas Schouten bschou...@mozilla.com Sent: Tuesday, August 13, 2013 10:34:38 PM Subject: Re: vsync proposal A couple things that are not clear to me from this proposal: - when the vsync event is sent? Depends on the platform. I believe on Windows we can call DwmFlush on a helper thread and fire it when that returns. Calling DwmFlush is bad. Calling http://msdn.microsoft.com/en-us/library/windows/desktop/bb174559%28v=vs.85%29.aspx is better. - how does it deal with a blocking swapbuffers()? Blocking swapbuffers isn't really compatible with having multiple windows on one compositor thread. If we want to move each window compositor to its own thread and keep blocking on swapbuffers, then we'll have to revise this proposal. Do we need to do that? I don't think we are ever forced to have a blocking SwapBuffers. All in all I have some concerns with the current plan. I believe the basics are solid, having a thread (or some other method) generate Vblank events is a good thing. I also believe using that to drive animations and some other things is a good idea. I think that should be decoupled from the Compositor though. I've discussed this a little on IRC and we've talked a little about this in the graphics meeting, one concern in particular I have with this idea is the idea that you have 'low latency' windows and 'high latency' windows, I think that's not true. Rather, I think there's drawing where the latency doesn't really matter, and drawing where it does. Here's some quick ideas I had about things (very rough around the edges still): First let's conclude we're not trying to do a vblank synchronized present, so we're not really vsyncing here (the preventing tearing discussion is completely separated as far as I can tell), we merely want to use the vblank signal to determine if a frame has been presented to the monitor. Take into account I have little idea of how the RefreshDriver currently works. Then what you basically have is two sorts of drawing: - Drawing related to user input (panning/zooming/etc), where ideally you need minimal latency - Drawing related to things we know in advance, video, animations, etc. Then there's requestAnimationFrame, which I guess is kind of special, I don't know enough about it to have a good idea when that should happen, I suppose vblank is as good a time as any? Since you want composition to occur whenever drawing has occurred, I don't really think it should really be what's working on doing any processing for the vblank event. The VBlank event should just fire, indiscriminately whenever VBlank occurs. I believe we should then consume that event on whatever thread is actually doing drawing which might want to know about this (a user input thread? the main thread?) and these should then decide when to do their drawing and if that warrants a new composition. That way you could have, just after vblank, all your scheduled drawing be done, and a composition scheduled. But then if right before the next vblank a panning/zooming event comes in you can still process that and present a new frame to minimize latency (if desired). What you could also do is do all your main thread drawing and processing rAF things just after vblank, since they'll likely be somewhat time consuming, and schedule your composition only for example 5 ms before VBlank (since that will likely be fast). You could then make some adjustments to the layer tree through the APZC for user input later in the frame, and still have those taken into account for composition, that would give you a minimal input latency without wasted work and still starting the content drawing required as early as possible giving it maximum opportunity to make the next frame. This may be a little bit too complicated for a first implementation, but I wanted to throw it out there as a suggestion as well. Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Exposing the CSS/SVG Filters as Canvas API's
Just to provide something of an update here. Let me first correct something from the original e-mail, SVG does not render on the Skia backend right now, but rather on thebes. It simply has its own code to do these sorts of filters. Over the last couple of weeks we've also been working on adding these filters to Moz2D. We now have software implementations on all backends (basically our SVG filter code migrated to work inside Moz2D) and hardware implementations for the Direct2D 1.1 backend which should be landing on central soon. Direct2D 1.0 users would technically speaking be the only tricky thing, the filter implementation there has been done so that -if- Direct2D 1.1 is available on the system, hardware accelerated filters will be used, if it's not though (Windows 7 pre platform-update or Windows Vista), those users would be facing readback. Since the long-term goal is to move all Direct2D users to Direct2D 1.1 I don't think this will be a large problem though. Best regards, Bas - Original Message - From: Jet Villegas j...@mozilla.com To: Jeff Muizelaar jmuizel...@mozilla.com, mozilla.dev.platform group dev-platform@lists.mozilla.org Cc: Tobias Schneider schnei...@jancona.com, Benoit Jacob bja...@mozilla.com, Boris Zbarsky bzbar...@mozilla.com, L. David Baron dba...@dbaron.org, Robert O'Callahan rocalla...@mozilla.com, Jonas Sicking sick...@mozilla.com, Bas Schouten bschou...@mozilla.com, Michael Bebenita mbeben...@mozilla.com, Yury Delendik ydelen...@mozilla.com, Claus Wahlers cwahl...@mozilla.com, Jeff Dyer jeffd...@acm.org, Till Schneidereit tschneider...@mozilla.com, Markus Stange msta...@mozilla.com Sent: Thursday, August 8, 2013 7:39:37 PM Subject: Exposing the CSS/SVG Filters as Canvas API's Shumway team still needs to implement filter effects available in the Flash Player. Ideally, fast filters can be made available to all Canvas programs. Now that we've got a shared filter pipeline with SVG and CSS, can we surface the same filters as a Canvas API? I'm attaching our last e-mail thread on the subject for context. --Jet - Original Message - From: Jeff Muizelaar jmuizel...@mozilla.com To: Tobias Schneider schnei...@jancona.com Cc: Jet Villegas j...@mozilla.com, Benoit Jacob bja...@mozilla.com, Joe Drew j...@mozilla.com, Boris Zbarsky bzbar...@mozilla.com, L. David Baron dba...@dbaron.org, Robert O'Callahan rocalla...@mozilla.com, Jonas Sicking sick...@mozilla.com, Bas Schouten bschou...@mozilla.com Sent: Friday, July 20, 2012 8:17:44 AM Subject: Re: Native implementation of Flashs ColorMatrix filter This is not that easy for us to do. The only Azure backend that makes this easy is Skia. None of CoreGraphics, Cairo or Direct2D support this functionality. We could do hardware/software implementations on top of those APIs as we do with SVG but I'm not in a huge rush to do this work. -Jeff On 2012-07-19, at 9:20 AM, Jet Villegas wrote: Here's a request from the Shumway team re: Canvas2D graphics. Can we surface this API? -- Jet - Forwarded Message - From: Tobias Schneider schnei...@jancona.com To: Jet Villegas j...@mozilla.com Sent: Thursday, July 19, 2012 8:40:52 AM Subject: Native implementation of Flashs ColorMatrix filter Hi Jet, as already discussed in some meetings, it would be big performance benefit for Shumway if we could implement Flashs ColorMatrix filter natively as an extension to the Canvas API. ColorMatrix filters (or more the ColorTransformation, which can be easily converted to a ColorMatrix) are used really often in Swiff files, e.g. there is no way no change a display objects opacity except of using a color transformation (or via script of course), so its really a highly needed feature for Shumway. And doing bitmap filter operations pixel wise with plain Javascript is just too slow to archive a decent frame rate (especially since Canvas is hardware accelerated, which makes using getImageData a pain in the ass). You can find out more about the ColorMatirx filter in the SWF spec or here: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/filters/ColorMatrixFilter.html Firefox already implements a ColorMatrix filter in its SVG implementation, but since SVG is currently using the Skaia graphics backend, I'm not sure if its possible to use them internally within the Canvas API, which is based on Azure/Cairo. So I digged a little bit deeper into Azure to see where it could be implemented, and i think the way we blur pixels to draw shadows is kinda similar. So maybe we can reuse a lot of that for additional bitmap filters. The Canvas API for it can look pretty simple, we just need a way to assign the ColorMatrix values as an array to a context property like so: ctx.mozColorMatrix = [1, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 0]; I'm pretty sure that once we've created the infrastructure to support bitmap filters on a Canvas, its
Re: On indirect feedback
Although I agree fully that by far the best way of offering feedback is by talking to that person directly. I do think we have to face the fact that at this point in time a significant amount of people find it very hard to speak to people directly about things. Even when their intention is to provide constructive criticism, they will often rather avoid the confrontation for fear of creating grudges, damaging their reputation, their career, etc. It also simply takes some amount of training and social skills to deliver criticism in such a way that the target of that feedback will perceive it as the intent to improve them, rather than an attempt to simply criticize them or even bring them down. On the other hand I think it's important for everyone I think to work on both their ability and willingness to -receive- feedback, as well as to provide it. An environment where people feel comfortable talking to other people with their feedback will only really come about when people on the receiving end of feedback keep an open-mind to that feedback and treat it as an honest attempt from the other person to help them improve themselves. In that sense it's a shame we don't have a 360-degree feedback process in affect with Mozilla at the moment, I firmly believe that can positively contribute to creating an atmosphere where providing your co-workers with feedback on the things they are doing and how they're doing them is simply part of day-to-day operations. In the end as long as there's people uncomfortable/afraid/unable to share their feedback directly, it would still be a good thing if they provide that feedback to their 'leaders' (managers/module owners/etc.) as they will hopefully be able to take that feedback and use it in a meaningful way to improve others, this is part of their job after all. I think this form of indirect feedback is much preferred over building up long term irritations or simply spewing negative comments over the watercooler :-). Just my two cents, Bas - Original Message - From: Robert O'Callahan rob...@ocallahan.org To: Brian Smith br...@briansmith.org Cc: Mozilla Product Builds dev-bui...@lists.mozilla.org, dev-platform dev-platform@lists.mozilla.org, Gregory Szorc g...@mozilla.com Sent: Saturday, August 3, 2013 1:28:39 PM Subject: Re: On indirect feedback On Sat, Aug 3, 2013 at 12:43 PM, Brian Smith br...@briansmith.org wrote: I think some people may interpret what you say in that last paragraph the opposite of how you intend. I am pretty sure you mean something like If somebody starts to complain to you about somebody else, then stop them and ask them to first talk to the person they were trying to complain about. Yes, that's exactly what I mean. Thanks. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Layers Refactoring Landing
Hey all, Last night we've landed the layers refactoring. This was a very large patch that had to be landed in one go. At the moment we are aware (and not completely surprised), that the first couple of regressions due to the refactoring have been found. We are working very hard with the entire graphics team and several people from other teams helping us to address the issues as they come in. We ask you all to bear with us as we try to figure out the problems that our test suites and internal testing didn't catch. Please reach out to us if you run into serious issues and don't back out straight away! If we cannot resolve the more blocking issues within a day or so we plan to take care of the backout ourselves. Thanks in advance for your patience and understanding! Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Moz2D Repository Creation
Hi all, Over the past year we've increased our dependencies on Moz2D (formerly known under the codename Azure), our new 2D rendering API. Currently we're using it for canvas drawing on all platforms and content drawing on Windows where using Direct2D, and in the near future we will be moving to using it for content on all platforms. From the very beginning of Moz2D development we've taken care to make sure it can be built outside of the rest of Gecko, having only dependencies on several MFBT headers. This was done to reduce the barrier for external usage and development, we've since seen this benefit us for example in Servo using Moz2D as well. In addition to that it has helped development and bugfixing by having a much faster workflow for building/testing with which bugs could be located and fixes created. Going forward we're expanding on that by ensuring the stand-alone builds and works on all platforms and becomes the defacto way of the 'first level' of testing when implementing new features or fixing bugs in Moz2D. In addition to that we're expanding on our existing stand-alone unittesting suite as well as adding a peformance testing suite, which will include microbenchmarking and support measuring performance on Moz2D drawing recordings (single-page recording support has just landed on mozilla-inbound). When moving forward we have several goals for Moz2D when it comes to the workflow: - Improve Moz2D development workflow by having faster turnaround time on builds and tests (both local and Try) - Lower the barrier for external contributors, some people have already expressed the desire to work on potential backends we do not wish to invest in ourselves, but have been deterred by the complexity of the checkout/building process. - Improve sharing between Servo/Gecko. - Reduce load on our infrastructure by building and testing only Moz2D stand-alone when a change affects only Moz2D, both on regular builds and try. As the next step in moving towards these goals and optimally supporting them the proposal is to move Moz2D into its own repository. We would use hg subrepos for this purpose, you can read more about this here (http://mercurial.selenic.com/wiki/Subrepository). The intention is that this will be done in such a way that the workflow for developers not involved in Moz2D development would essentially not change. A more detailed description of the proposal and the workflows involved can be found here (https://wiki.mozilla.org/Platform/GFX/Moz2DSubrepository) for those interested in the details. Since we believe if we go through with this it would be the first time we use a true subrepository system for a component used in mozilla-central, we'd very much appreciate any thoughts or feedback people might have on the idea. Best regards, Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
Personally I don't care if we use Git or Mercurial, what I do feel fairly strongly about is that whatever we do for Moz2D runs on our own infrastructure. If that infrastructure supports git I have no issues with it being in git. Although I've done my testing with hg subrepos only. For what it's worth I personally find our mix of mercurial and git extremely disturbing, and this once again goes to show the amount of problems that come from such an architecture. I'd find it quite sad if the fact we're in this situation would block progress on this front. As to subrepository functionality, they seem to work well for our purposes, it's true that some complexities arise if you would like to do certain operations across repository boundaries but I didn't see a lot of cases where we'd actually want that. For what it's worth, I've worked with SVN externals before and found them quite nice to work with. But I must admit my experience with hg subrepos is limited to the testing I did. I've heard stories that mercurial subrepos work a lot better than git submodules, however I have even less experience with the latter. One argument for hg subrepos is that their type of functionality is pretty much -exactly- what we want/need for a great experience. This could be true for git submodules as well, but I have no idea if it is. Bas - Original Message - From: Justin Lebar justin.le...@gmail.com To: Gregory Szorc g...@mozilla.com Cc: Bas Schouten bschou...@mozilla.com, dev-platform dev-platform@lists.mozilla.org Sent: Wednesday, March 27, 2013 10:06:56 PM Subject: Re: Moz2D Repository Creation hg-git (the tool we use to synchronize Mercurial and Git repos) supports subrepos. Although, I'm not sure how well it works. Well, we should definitely figure this out before we move forward with this plan. If the hg support for git repos is decent, that might be a better way to go, since then we'd have one fewer repo we needed to mirror for B2G's purposes. Assuming that hg-git is happy with git submodules. :) I haven't met many Git users who enjoy submodules, myself included. Git submodules suck, but so does importing library code via cp, as we do now. :-/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
I would argue this is probably true. As I've talked to a developer from a large third party where the discussion of if they would try to adjust their work to Moz2D literally ended at: 'I have to check out -all- of firefox? How big is that 2 Gig or something?' I think it's certainly the largest practical and mental barrier. Best regards, Bas - Original Message - From: Robert O'Callahan rob...@ocallahan.org To: Bas Schouten bschou...@mozilla.com Cc: dev-platform dev-platform@lists.mozilla.org Sent: Wednesday, March 27, 2013 10:14:35 PM Subject: Re: Moz2D Repository Creation On Thu, Mar 28, 2013 at 9:42 AM, Bas Schouten bschou...@mozilla.com wrote: - Improve Moz2D development workflow by having faster turnaround time on builds and tests (both local and Try) - Lower the barrier for external contributors, some people have already expressed the desire to work on potential backends we do not wish to invest in ourselves, but have been deterred by the complexity of the checkout/building process. - Improve sharing between Servo/Gecko. - Reduce load on our infrastructure by building and testing only Moz2D stand-alone when a change affects only Moz2D, both on regular builds and try. Seems to me that of those goals, only lower the barrier for external contributors actually *requires* Moz2D to be in a separate repository. Is that right? Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moz2D Repository Creation
Thanks a lot for thinking along here from the RelEng side of things! - Original Message - From: Alex Keybl ake...@mozilla.com To: Bas Schouten bschou...@mozilla.com Cc: dev-platform dev-platform@lists.mozilla.org Sent: Wednesday, March 27, 2013 11:25:14 PM Subject: Re: Moz2D Repository Creation Can you clarify the main motivation behind using a subrepo over a Tier 1 dev branch like m-i or services-central? Mimicking what we already do elsewhere would have less process/infra change overhead, and my intuition tells me that per-checkin builds/tests could be configured specifically for that repo. Perhaps we should be focusing mostly on your point about Improv[ing] sharing between Servo/Gecko though. The main motivations would be: - Reduced tree size (for clone/pull/update/etc.) - Easier bisection within the specific Moz2D code. - Cleaner merging system (i.e. rather than merging, it would just be a revision tag update in m-c) Assuming we move forward with a subrepo, a few thoughts: * Whatever the branching model becomes, it sounds like it'll end up being around merges. Just let us know what you'd like us to do at m-c-m-a and upon subsequent merges. No problem there. Nothing should change for that, m-c - m-a would just take the currently tagged revision along with it, and that would remain the revision used. For upstreaming patches the process gets a tiny bit different, see also your point below this one. I've added some of my own thoughts to the wiki page. * We'll need to decide how to handle approvals - whether to gate at landing to a branched subrepo, or updating the changeset in the main repo. Just requires some discussion. * Somebody (engineer, sheriff) would need to make sure that after landing to a subrepo branch, a version of Firefox is marked as fixed once it the changeset starts being referenced from the main repo. Yeah, this is an interesting point. The question is if it's defined fixed by being fixed on Moz2D or in Firefox, probably the latter is best. As for impact to QA and investigations, I agree that the change should be fairly minimal. Since we'd still like the help of contributors and QA in bisecting a day's worth of Moz2D changes, new documentation may be necessary. Indeed, a day (or a week) worth of Moz2D changes will be a lot easier to bisect though! :-) And could even be done within m-c where you'd for example only have to rebuild gfx/2d and layout/media, as long as your bisection doesn't include API changes. This would be one of the advantages of the separation listed above. -Alex Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Minimizing Layers churn for refactoring
Hi all, Over the last couple of years there were a lot of new additions and changes to the layers sytems which have caused the current implementation to become hard to maintain with a lot of code duplication. The graphics team has been working hard on re-designing part of the layers system, this also means refactoring a significant portion of the existing code. Since this means a lot of work this is being executed on the Graphics project branch. As we are getting closer to completing the work (although completion is still some ways off), it's becoming increasingly difficult to merge work being done on mozilla-central. In light of the end-goal of having a layers system that's easier to amend and maintain as soon as possible we'd therefore like to ask everyone working on the platform to minimize work done on layers, and to make sure all patches going into this part of the code to receive explicit review from somebody on the graphics team. If you have any questions or want to learn more about the refactoring feel free to contact myself or another member of the graphics team. You can find the refactoring work on https://hg.mozilla.org/projects/graphics. Best regards, Bas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko switched to use standard integer types
Is ptrdiff_t not portable? As far as I know it's part of the standard. - Original Message - From: Makoto Kato m_k...@ga2.so-net.ne.jp To: dev-platform@lists.mozilla.org Sent: Friday, August 24, 2012 1:30:39 AM Subject: Re: Gecko switched to use standard integer types How about PRUptrdiff? Most cases can changes to uintptr_t. On 2012/08/23 1:35, Ehsan Akhgari wrote: I just landed the patches in bug 579517 which switch all of the code in mozilla-central and comm-central [1] to use the standard integer types as opposed to NSPR integer types. Here's what this means to you: * If you're a developer, this will most likely bitrot your patches. You can use this script [2] in order to unbitrot your patches if you use mercurial queues. Also, please get into the habit of using stdint types (such as int16_t and uint32_t) as opposed to NSPR numeric types (such as PRInt16 and PRUint32). * If you maintain a branch which merges against mozilla-central, you probably want to merge mozilla-central into it as soon as possible. There will probably be merge conflicts. The easiest way to resolve them is to take your branch's version in the conflicts and then run the script that I used for the conversion again so that you make sure you're not adding more NSPR numeric type usages in your branch. * If you want to back out a patch which landed before this, there's probably a bunch of manual conflict resolution that you need to do. * If you talk to new Mozilla contributors regularly, you probably won't need to explain to them what these NSPR types are any more. :-) * If you're not in any of the above categories, this work will probably not affect you. Cheers, Ehsan [1] (except for NSPR and NSS) [2] https://bugzilla.mozilla.org/attachment.cgi?id=650572 [3] https://bugzilla.mozilla.org/attachment.cgi?id=653946 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
