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.
