I have some code that might help you here. What I tend to do is query for the window size on application init
and also create a subscription to Browser.Events.onResize
. Assuming its a fullscreen SVG app, this size is converted into the SVG viewport. If the SVG part was not fullscreen, its more complicated because although you can query for the viewport of anything in the DOM, there is no ResizeObserver
like thing in Elm. You can opt to set that up with ports, or if you know that something is only going to change size if the window is resized, just re-query it after the Browser.Events.onResize
subscription is invoked.
Initial sizing request from Browser.Dom.getViewport
is here:
https://github.com/the-sett/tea-tree/blob/master/example/src/elm/Main.elm#L139
The subscription for ongoing window resize events is here:
https://github.com/the-sett/tea-tree/blob/master/example/src/elm/Main.elm#L120
The reason that I query for the window size, rather than just letting the SVG fill the window with its CSS styling, is that I want to set up the SVG viewBox
to exactly match its on screen size in pixels. This is done here:
https://github.com/the-sett/tea-tree/blob/master/example/src/elm/Main.elm#L258
I find having the SVG exactly match the window size 1:1, makes rendering sharp looking SVG much easier.
For example, when rendering a line 1px wide, if it is a vertical line, its x coordinate needs to be offset by 0.5 px, so that the line is drawn right down the middle of the pixels, if you see what I mean? Another way you can do this is to offset the SVG viewport origin by 0.5, to make the math ‘easier’. Of course, its not always easier that way, as now a 2px wide line needs adjustment.
One thing I have not done in this application is to take into account the device scaling ratio. For example, on my current screen it is 1.5, so each SVG unit is 1.5 physical pixels, which can lead to blurry edges - It matters less on a high DPI device though.