On Thu, 14 Dec 2017 21:10:06 +0800, Anton Shestakov wrote: > On Thu, 14 Dec 2017 21:07:38 +0900 > Yuya Nishihara <y...@tcha.org> wrote: > > I'm okay with this change, but it might be bad in UX as the resize occurs > > very late. > > I don't think the way it's resized now would cause any problems: > > - <canvas> is an absolutely-positioned element that is simply stacked on > top of the list of commits, which means the rest of the page doesn't > really depend on its size, > > - it is also fully transparent initially and after any resizing, so its > size is not something that can be easily seen without devtools, > > - and most importantly, while the way JS code updates the page has been > changed from > > resize <canvas>, copy new HTML, render on <canvas> > > to > > copy new HTML, resize <canvas>, render on <canvas> > > DOM updates still happen only when scripting has finished the > execution (if it's synchronous, like in our case), so the result can > only be seen after all three "functions" complete anyway, > > I think even if we switched to SVG and did the resizing part at the > very end, it would still be only one "visible" update to the page > (I'll do some experiments when I actually try to do graph in SVG).
Well, I see difference on Firefox 57. Perhaps the initial padding-left of data-node had a reasonable value before. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel