[PATCH 2 of 4] hgweb: calculate <canvas> width and height client-side
Yuya Nishihara
yuya at tcha.org
Thu Dec 14 09:01:18 EST 2017
On Thu, 14 Dec 2017 21:10:06 +0800, Anton Shestakov wrote:
> On Thu, 14 Dec 2017 21:07:38 +0900
> Yuya Nishihara <yuya at 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.
More information about the Mercurial-devel
mailing list