I was able to see memory allocations climb rapidly in one test until it died though, when I was holding `down`.
On Wednesday, August 31, 2016 at 8:57:56 AM UTC-6, OvermindDL1 wrote: > > Chrome, Windows 10 (I'm at work, this is not my main OS). Every time I > tried to profile the tab would get slower and slower over a period of just > a few seconds until the tab itself died. > > > > On Wednesday, August 31, 2016 at 8:49:01 AM UTC-6, Alex Spurling wrote: >> >> Thanks, that is good to know! I wonder what exactly caused it to blow up. >> I've done profiling on both Chrome and Firefox and never had it blow up. >> What browser and OS are you using? >> >> Alex >> >> On Wednesday, 31 August 2016 15:27:22 UTC+1, OvermindDL1 wrote: >>> >>> Well if it helps I hooked up a profiler to the page and ran it, it >>> exploded and died due to memory allocations. Unsure where since it died... >>> >>> >>> On Tuesday, August 30, 2016 at 5:23:51 PM UTC-6, Alex Spurling wrote: >>>> >>>> I've made a little canvas drawing app in Elm which unfortunately >>>> suffers from some weird performance behaviour. Here it is in action: >>>> >>>> https://alexspurling.github.io/quickdraw/ >>>> >>>> The design of the game is like this: >>>> >>>> update msg model = >>>> case msg of >>>> CanvasMsg -> >>>> --Update the model with the latest mouse position, drawing state, >>>> zoom level etc >>>> AnimationFrame time -> >>>> --Calculate the line to draw on the canvas (if any) >>>> --Dispatch the commands needed to draw a line or resize the >>>> canvas >>>> >>>> The idea of this design is that it minimises the number of canvas >>>> update commands needed (we don't need to update the canvas more than 60 >>>> times a second). >>>> >>>> If you try to draw on the canvas, you should notice a steady 60fps >>>> while drawing. The performance issue hits when you try to zoom out. The >>>> zooming action works well enough, but if you then try to draw on the >>>> canvas, often the framerate will drop to 10fps or so. However - and this >>>> is >>>> the bit I cannot understand - if you simply wait 60 seconds or so and try >>>> to draw again, fps will be back up to 60. >>>> >>>> I've just uploaded a new build that reproduces the problem a little >>>> more easily, instead of zooming, simply press and hold the "down" arrow >>>> key. While holding down, try to draw on the screen and you should notice a >>>> drop in frame rate. Now, let go of "down" and keep drawing. You should >>>> notice that the framerate still stays low. (If you don't notice the drop, >>>> try zooming out with the mouse wheel and try again). >>>> >>>> If you take a look at the code ( >>>> https://github.com/alexspurling/quickdraw/), holding the "down" key >>>> performs this update: >>>> >>>> TestMsg -> >>>> let >>>> _ = Debug.log "Test msg" 0 >>>> _ = loop 1000000 >>>> in >>>> model ! [] >>>> >>>> loop : Int -> Bool >>>> loop val = >>>> if val == 0 then >>>> True >>>> else >>>> loop (val - 1) >>>> >>>> Each call to this event triggers a CPU heavy loop. I would expect >>>> framerate to suffer while Elm handles this update. But why do I still get >>>> low framerate long after these events have all been processed? >>>> >>> -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
