The purpose of the SafeFrame in any CAD software is to enable an accurate preview “in camera” of the elements which are going to be visible in a final rendering (or in a CaptureViewToFile). Therefore the Safeframe should also respect portraitmode and resolutions higher than the monitor is running. It has never been the case in Rhino in 6, 7 SR1-37 or in 8 SR1-7. The SafeFrame implementation is awfull and not usefull for eg 900x1800 px or 1200x1600 px if you run on a 1920x1080 px monitor. You just need the aspect ratio to be correct. You don’t need it to show pixels in 1:1, and you have no need for other options than the “Live Action” as the default if the color can be set to any color (not always yellow).
This issue has been reported multiple times on Windows since 7 and 6 - maybe even Rhino 5.
is this one for you @Andy ? - I believe we also talked about this issue at 3XN’s office last year?
Thanks @dale. As I understand it, this issue is now more than 11 years old. Would be nice with a timeline. SafeFrame work very nicely on plugins using their own Virtual Framebuffer like Enscape. Maybe a first stepping stone could be to fix the SafeFrame in a floating window in Rhino 8’s GUI?
There will not be any new features added to Rhino 8. Anything new will appear on Rhino 9.
– Dale
Any chance it can get into WIP, so users can comment on the implementation before launch? The SafeFrame feature and the GUI of the VirtualFraneBuffer are both critical in the quest for onboarding more users to use Cycles as their primary renderer.