Re: Automatic tree clobbering is coming
Just my opinion on this, I don't care enough to argue it more than this; rm -rf any directory in response to configure, by default, is *not* expected, or reasonable behaviour. Rather than having an environment variable to turn this off, it should be the other way round. I can see people getting caught out by this, even one of the students I was mentoring stored things in the objdir (against my advice, mind, but all the same). I think it's a reasonable statement to say that people don't expect a configure script to delete things, especially things it may not have created. Either there should be a more reliable clean-up method, or I don't think this should be default behaviour. --Chris On 01/04/2013 19:24, Gregory Szorc wrote: On 4/1/2013 11:00 AM, Jeff Hammel wrote: On 03/29/2013 06:01 PM, Gregory Szorc wrote: snip/ I highly recommend against defining MOZ_OBJDIR in terms of relative paths. You're implicitly creating a dependency on cwd. This is handy in a few use cases but it's a giant foot gun. Instead, do something like |mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-firefox|. I have MOZ_OBJDIR (generally) = @TOPSRCDIR@/../obj-browser ; is this unsupported? I generally don't like putting the objdir as a subdir as the srcdir for various unimportant reasons not worth discussing on list. This is supported and should work fine. MOZ_OBJDIR is anchored to TOPSRCDIR, which should always resolve as an absolute path. ___ 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: Off-main-thread Painting
On 12 February 2013 21:57:53, Clint Talbert wrote: I agree in part with the assertion about testing - that the existing reftests will catch most regressions stemming from this. But I think we also need some measurements around scrolling/responsiveness in order to verify that off main thread painting is giving us the wins we hope it will give us. Part of that is knowing where we are now, and then seeing how that measurement will change once this work lands. We can use Eideticker for doing some of this measurement (particularly for blackbox end-to-end measurements, but it would be even better if there were some way to instrument the paint pipeline so that we could get measurements from inside Gecko itself. If we can instrument it, we can run those tests per-checkin on all our products. So I'd encourage you to put a bit of thought into how you might do some light weight instrumentation in this code so we can verify we make the gains we hope to make here. Clint It's probably worth noting that this instrumentation already exists for Android, in the form of talos pan and checkerboard tests. It would be good to have something for other platforms if it doesn't already exist though. --Chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Off-main-thread Painting
On 12 February 2013 13:05:33, Jean-Marc Desperrier wrote: Matt Woodrow a écrit : to improve both performance and responsiveness of the browser, we are planning on moving painting to happen on a separate thread. I think you should take some time to consider what impact it has on the synchronization between interactive events and what is visible. - Browser receive the order to draw Y above X - I click on X that I'm still seeing - Browser asynchronously actually draws Y What does the browser consider I clicked on ? It may happen that the browser considers I clicked Y while I was seeing X. Especially if the intend is to improve responsiveness, which means that I can click whilst the browser is painting, so it may be unclear what I intended to click on. I'm not sure this situation is really affected at all. This would be an issue currently with just OMTC, as well as under the proposed scheme. A similar situation that could happen is that you scroll down and the page changes in response to the scroll change. This would still be an issue with current asynchronous compositing, but the difference is you may get to an area with just OMTC that would be blank, where as it would more likely be visible (and incorrect) under this scheme. Neither of these situations are an issue until rendering takes a significant amount of time, though. The proposed scheme might actually make this easier to fix. We currently do hit detection by drawing a pixel of the display list (I think?) and seeing what gets drawn. If we're separating the display list from external dependencies, we could theoretically use it for hit detection so that there isn't a mismatch between what's on the screen and the current Gecko-side state. I think it'd be more sensible to look into this if it ever becomes an issue, but certainly something to consider. --Chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
