Dpi scaling on Windows 10 with RhinoCommon


I have a feature handled between Rhinoceros 5 and Windows Control Panel that is not working anymore in Rhinoceros 7: the size retrieved from the call using (Graphics g = Graphics.FromHwnd(Rhino.RhinoApp.MainWindowHandle())) { return new Size((int)g.VisibleClipBounds.Width, (int)g.VisibleClipBounds.Height); }
and the rendered result on screen of a WPF Window setted as child of Rhinoceros 5 Window was including the effect of the scale parameter setted in Windows Control Panel.

With Rhinoceros 7 the call mentioned is invariant to the dpi scale parameter, and as a consequence a WPF Window with the Owner equal to the Rhinoceros Window is not scaled up anymore automatically (in Rhinoceros 5 with a 2K screen with 125% dpi scale, the Graphics size returned was 1500x600 but was rendered in 1900x1000, displaying bigger internal controls as expected by the setting in Windows Control Panel)

Is there a parameter that activates this windows display pipeline feature? Or I have to handle this scale internally on each mouse / hud interaction between the WPF controls and the Rhinoceros Viewport3D?

Hi @cavalli.stefano,

Unlike Rhino 5, Rhino 6 and above are high-DPI aware. Here are a couple of developer notes on the topic.

– Dale

Ok thanks for the redirections.

It seems that a WPF Window setted with the owner equal to Rhinoceros 5 Window had a built in Microsoft Windows display renderization in which
1- the full screen Rhinoceros Window declared a smaller size from the Graphics.FromHwnd instance described in my last post when the dpi scale is bigger than 100%
2- the WPF Window then created a renderizable layout with same constant control size of the inner controls and smaller window size (the wpf window layout on my Rhinoceros plugins is always a small frame around some sides the viewport3D)
3- the scale up to the actual display size made by the Rhinoceros 5 Window resulted in bigger controls and same 3D Viewport.
4- the final result was that the elements with constant size were bigger to allow more compression in monitors with high DPI (usually used to draw high resolution content, I have only vectorialized info, but in my case easier acces by having more renderized area with hittest capabilities)

I’m investigating if this is still possible and I’ll let you know if I find a solution different than introducing this scale from mouse interaction and to 2D overlayed drawings over the Viewport3D.

I have implemented the details inside the pages as suggested in the documentation. I haven’t found a solution to redirect to the rhino5 behavior.