javascript - Chrome doesnt show large sized canvas -

i have application draws on 260 plots on canvas. decision put them on single canvas dictated speed considerations - faster way various tasks (such zooming , panning). i.e., splitting 260 canvases not option in case.

everything works fine on opera, firefox , ie. chrome, however, stops displaying canvas when height becomes larger ~8130 pixels (the width constant - 834 px).

i.e. have ability add/remove charts on fly (they stacked 1 upon another), , once height exceeds 8130 px chrome "hides" canvas. remains responsive , no error thrown - reason?

although standard specify unsigned long size canvas:

interface htmlcanvaselement : htmlelement {            attribute unsigned long width;            attribute unsigned long height; 

^{source: whatwg/canvas element}

most browsers seem limit size 8192 (safari apparently 6826).

in case (generally speaking) -

if need canvas size bigger should re-think design. canvas should need bigger can see on screen. consider canvas view-port data not holder of it. how operating systems works (at low-level) has proven best approach on decades.

consider band-width requirements (not accurate based on implementation , optimizations - sake of pointer we're dealing with):

a canvas size of 8192 x 8192 pixels using rgba buffer consumes 256 mb raw memory (and depending on browser implementation double).

update @ 60hz , band-width minimum 15 gb/second. in addition other browser , system content adds this. if used @ typical consumer computer (and not on developer machine) theoretical benefit lost.

yes, can gain speed pre-render large area , move view-port blitting pixels visible 1 - point , cost (memory being 1 factor). of speed gain anyway lost using javascript move "blitting source" around compared more low-level environments gain more significant.

it's in general better keep data in vector format (array/typed array/object) , plot visual portion of checking boundaries, ie. data visible in view-port. can optimize data in various ways access fast (see instance quad-trees).

render vector data not costly 1 might think (if done "correctly") , smaller canvas faster clear , redraw data.

the main trick blit content on canvas (same effect blitting huge canvas) , update new gaps.

my 2 cents..