[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