Screen space coordinate systems (insets, annotations etc)

[jlstevens]

HoloViews is designed around the separation between data (what is inside Elements) and plotting/display concerns. This often works very nicely but there are cases where the distinction gets a little blurred, particularly with various sorts of annotations.

Annotations often do contain data but many annotations (e.g arrows) are useful when positioned in screen space as opposed to data space (where screen space is typically a property of display, using units such as points, pixels etc). Another instance where this distinction is important is when deciding zooming behavior (typical for the bokeh backend): should the area of presentation zoom with the data or should it be a fixed size on the screen regardless of zoom level?

Insets (discussed in #175) are another example of something that lives in screen space. One proposal that might help unify things is the notion of a ScreenElement which would be an element living in screen space (but is also aware of the data coordinate system). Annotations and insets would then be screen elements. Although this proposal is attractive in some ways, it doesn't address many real world complexities. For instance, you may want to specify the position of an arrow head in data space but the width of the arrow in pixels (screen space).

This issue was touched upon in PR #346 and issue #175 regarding insets is also relevant. In the PR, it was suggested that xunits and yunits could be plot options that could have values 'data' and 'screen'.

This issue is intended to allow us to discuss such proposals in more detail.

[jbednar]

It seems like one often wants to choose between either screen or data coordinates, and that one should be able to designate which one a given parameter is applied to. I don't think xunits and yunits would help, e.g. for the arrow width case; the position is in data units, but the width is in screen units. What's the trouble, exactly? Seems like as long as we specify each one in the right system, we'll be happy.