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.
