google chrome - Why is WebGL render speed so inconsistent? -

in application plot 8 million vertices single call webgl's drawarrays using line_strip flag. don't want 1 long line, want 200k short lines, cap short lines vertices, , tell vertex shader "push" line caps negative z create invisible bridges. rendering quasi-static (the user can click various things trigger re-render) doesn't have super-fast, i'd hoped take less 200ms on modernish computers.

on laptop [update: runs win7 using few intel i7s cpu , integrated hd graphics 4000 gpu] around 100ms in chrome, good. oddly though, firefox gets around 1-2 seconds. on samsung chromebook 550 600ms 2s, starts quick , subsequent renders slower can faster too.

questions:

• what might causing change in render speed on chromebook?
• why firefox slower chrome on laptop?
• is worth spending ages trying make run faster (i.e. can expect improvement)? tips?

notes:

• for chromebook repeated rendering tests, thing happening between renders uniform changed toggle between color palettes (implemented textures). chrome dev tools doesn't seem think there major changes in page's memory usage during testing.

• i'm using gl.finish , console.time see how long rendering taking.

• except during debugging, render orphaned canvas , copy sections of result various small canvases on page update: using drawimage (with webgl canvas first argument). take bit of time, numbers reported above don't seem change or without copy operation , or without webgl canvas attached page body (and visible).

• update: there limit how many vertices laptop render in 1 go, limit seems fluctuate moment moment, if go on limit doesn't render anything. number around 8million mark, it's happy go on 11million. i've set batch 2 million @ time. interestingly seems make chromebook go faster, can't sure it's inconsistent.

• update: i've disabled depth_test , blend don't need them. i'm not convinced made difference.

• update: i've tried rendering points instead of lines. on chromebook seemed take 1s 0 point size (i.e. rendering nothing), , around 1.5-2s increased point size through 1,2, , 5.

• update: keeping on z=0 plane doesn't seem change speed much, maybe goes little slower (which i'd expect there lot more pixels through fragment shader, though fragment shader funneling varying straight gl_fragcolor).

although usual (good) advice render as possible in each draw call, (at least 1 know of) gpus have internal buffers used while processing vertex data. exceeding capacity of these buffers can make performance fall off cliff. reduce size of vertex batches until start see performance drop having batches small.