I'm happy to implement some of these proposals in blink to compare the performance when the time comes, if I or other guys can afford to do. On Thu, May 7, 2015 at 1:20 PM Hayato Ito <hayato@chromium.org> wrote: > I'm wondering how we should estimate the performance impact of these > proposals. > > In the era of Web Components, I expect that one page has 1k Web > Components. The page must work without any significant noticeable > performance regression, compared to a page which doesn't use Web > Components. That's our bottom line. > > In the current distribution model, I expect we can achieve this goal, > thanks to the lazy evaluation of distribution. > > Is there any plan how we should evaluate these proposals in terms of > performance primitives? > > > On Thu, May 7, 2015 at 7:53 AM Ryosuke Niwa <rniwa@apple.com> wrote: > >> >> > On May 6, 2015, at 2:39 PM, Elliott Sprehn <esprehn@chromium.org> >> wrote: >> > >> > The 3 proposal is what the houdini effort is already researching for >> custom style/layout/paint. I don't think it's acceptable to make all usage >> of Shadow DOM break when used with libraries that read layout information >> today, ie. offsetTop must work. I also don't think it's acceptable to >> introduce new synchronous hooks and promote n^2 churn in the distribution. >> >> Sorry, I don't follow. If we're making offsetTop to synchronously return >> the correct value, then authors can easily write code that performs in >> Ω(n^2) by obtaining the value of offsetTop between adding/removing direct >> children of a shadow host. On the other hand, if we're trying to prevent >> O(n^2) behavior, then we should be adding API to asynchronously retrieve >> layout information. >> >> - R. Niwa >> >> >>
Received on Thursday, 7 May 2015 06:22:32 UTC