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.

Reply via email to