CSSTUDIO-2939 Add property "SVG Rendering Resolution Factor" to the Picture and Symbol widgets

[abrahamwolk]

This pull request adds the widget property "SVG Rendering Resolution Factor" to the Picture and Symbol widgets:

The functionality enables a sharper image when zooming in, at the expense of a quadratic increase in memory consumption. E.g., by setting the SVG rendering resolution factor to 2.0, an SVG can be rendered at twice the width and twice the height, but the memory required to represent the image grows by a factor of four.

This functionality is similar to the functionality implemented in #3197, except that the rendering resolution factor is now set per-widget.

[kasemir]

This is all quite unfortunate. The S in SVG stands for Scalable. Draw once, view in any size.
I guess there was no obvious way to directly display SVG in a JavaFX widget, so Batik was dragged in to convert SVG into a pixel image. Now the end user is expected to configure some internal scaling factor of that conversion? On each picture and symbol that uses SVG?!
Can't this be hidden? As suggested in #3197, make that a preference that the end user doesn't see, and only apply it when zoomed? Or automatically determine this scaling factor based on the zoom factor?
Or maybe reconsider how SVG is handled. Can https://docs.oracle.com/javase/8/javafx/api/javafx/scene/shape/SVGPath.html be used to directly render SVG?

[abrahamwolk]

This is all quite unfortunate. The S in SVG stands for Scalable. Draw once, view in any size.

I agree.

I guess there was no obvious way to directly display SVG in a JavaFX widget, so Batik was dragged in to convert SVG into a pixel image. Now the end user is expected to configure some internal scaling factor of that conversion? On each picture and symbol that uses SVG?!

The default is set to 1.0, which corresponds to the current default behaviour of Phoebus. The expectation is that this property is only set in widgets in a small subset of OPIs that are designed for zooming-in.

Can't this be hidden? As suggested in #3197, make that a preference that the end user doesn't see, and only apply it when zoomed? Or automatically determine this scaling factor based on the zoom factor?

The problem with the implementation in #3197 is that the memory consumption of many OPIs where zooming-in is not required can grow substantially.

The suggestion to apply the re-scaling only when zooming-in seems complicated to implement: zoom-events would have to be captured, and if several zoom-events happen in a short timeframe they would need to be processed in-order. In addition, the set of SVGs in the current OPI would have to be determined by recursing over widgets including possibly embedded displays and tabs. My intuition is that implementing this functionality correctly would be complicated, and I therefore prefer this more simple design.

Or maybe reconsider how SVG is handled. Can https://docs.oracle.com/javase/8/javafx/api/javafx/scene/shape/SVGPath.html be used to directly render SVG?

I have previously tried to use SVGPath to render SVGs, but I was not successful in my attempt.

[kasemir]

complicated

Yes.
If we could at least hide that property unless the image is an SVG, but we don't have an easy way to show/hide properties in the editor, so that would be its own side project.

Since this only applies to SVG, should we hack this into the image file name?
If your image is /path/to/image.svg, it's rendered with a scaling factor of 1, but you can enter an image name of /path/to/image.svg[x2.5] to get a scaling of 2.5? Yes, the file dialog wouldn't understand that, so whenever you use the file dialog to select an image, you then need to manually enter the "...[x2.5]" to the file name.

How big is the actual problem? What do your screens look like when you don't have that scaling factor? How about simply not using SVG in the displays? Batch-convert all your SVGs into PNGs of sufficient size (on Linux, use ImageMagic) and then use those in the display.

[georgweiss]

Due to the memory consumption impact I'd propose to add some kind of information to alert the user of the consequences of boosting the scaling factor. Maybe a tooltip, or an addition to one of the example OPIs.

[abrahamwolk]

If we could at least hide that property unless the image is an SVG, but we don't have an easy way to show/hide properties in the editor, so that would be its own side project.

Would it be OK for you if the widget property is hidden in the UI by default, but can be enabled by setting a special option in phoebus.ini?

[abrahamwolk]

Due to the memory consumption impact I'd propose to add some kind of information to alert the user of the consequences of boosting the scaling factor. Maybe a tooltip, or an addition to one of the example OPIs.

A tooltip would be a good solution I think, but unfortunately I think it is difficult to add due to the structure of the code: the tooltips are set in the class PropertyPanelSection and are constructed from property.getDescription() (which is also used for the text on the label itself) and property.getPath() for the tooltip of label describing the property, and from the entered value itself for tooltip of the TextField for entering the value of the widget property in the UI. None of these are good places to put a note about the memory consumption, I think.

[kasemir]

Would it be OK for you if the widget property is hidden in the UI by default, but can be enabled by setting a special option in phoebus.ini?

I like that.

[abrahamwolk]

I have updated the pull request to include the option org.csstudio.display.builder.model/enable_svg_rendering_resolution_factor (with default value false) for enabling/disabling the functionality.

[georgweiss]

What if a display file is created with the scaling factor and then opened in Phoebus where the property is disabled?

[abrahamwolk]

What if a display file is created with the scaling factor and then opened in Phoebus where the property is disabled?

Then no scaling is applied to the rendered SVG. If the OPI is saved, the original scaling factor is not present in the saved file.