Feedback on VFB2 User Experience and Suggestions for Improvement

Dear Corona Renderer Development Team,

Hello. I am a designer/artist who uses Corona daily, and I would like to provide some in-depth feedback on the VFB2 interactive interface. VFB2 is powerful, but in practical workflow, I believe several key adjustments could significantly enhance operational efficiency and the creative experience. Below are my specific suggestions based on high-frequency usage scenarios:

1. The Interactive Window Should Have a Reasonable Default Minimum Size

• Current Issue: During interactive rendering, the VFB2 window can be resized to an extremely small dimension (e.g., 106×106). This causes all parameter panels to auto-collapse, making the interface completely unusable. The user must interrupt their work and manually drag the window back to a usable size—a process that is both redundant and disruptive to creative focus.

• Core Suggestion: Set a reasonable default minimum size for the VFB2 interactive rendering window (e.g., a render view size of 500×500 or 600×500, similar to VFB1's initial logic). The window should only be allowed to enlarge from this minimum size, not shrink further. This would fundamentally prevent interface collapse due to accidental operation and provide a stable, reliable visual starting point for each interactive rendering session.

2. Simplify the Resolution Lock Logic and Return to Intuitive Window Operation

• Current Issue: The existing "resolution lock" mechanism is cumbersome. The user needs to: drag the region → render to preview → click twice to lock. If an adjustment is needed, they must unlock and repeat the entire process. The problem worsens when switching between cameras with different aspect ratios—the VFB window always resets to its default size, forcing the user to repeatedly perform the redundant operation of "enlarging the window → clicking lock."

• Core Suggestion: Remove the current manual lock button and adopt a more intuitive, automatic logic: The size of the VFB window should represent the user's desired view size. When a user resizes the window, the system should automatically treat this size as the target render view (similar to VFB1's behavior: the render view matches the window size). When switching cameras, the VFB window size should remain unchanged, and the rendered image should adaptively display within the window (scaled or with black bars). Simply put, the ideal logic should be: The render view follows and adapts to the user-set window size, rather than the window passively following and being constrained by the original proportions of the render image or camera. This would completely eliminate the cumbersome "lock/unlock" process.

3. Optimize Interface Space Utilization on High-Resolution Displays

• Current Issue: On mainstream resolution screens like 1080p (1K), the buttons and parameter panel controls in VFB2 are relatively large. They occupy too much valuable screen space, significantly compressing the actual display area for the rendered image.

• Core Suggestion: Unify and optimize the scaling logic for interface elements to make the layout of buttons, icons, and parameter panels more compact and efficient. It is suggested to refer to the control sizes and space utilization efficiency of VFB1 for adjustment, maximizing the display area for the rendered image while ensuring readability and operational precision.

Priority and Final Vision
I strongly recommend prioritizing the modifications mentioned in points 1 and 2 above. These two points are directly related to the core rendering operation flow and currently represent the biggest efficiency obstacles in daily work. Once optimized, the interactive experience of VFB2 would approach perfection.

To more intuitively demonstrate the potential of an optimized layout, I have attached several conceptual interface mockups for your reference:

• Optimized Layout Mockup: Shows how to utilize screen space more efficiently with a compact layout.

• Panel Collapse Mockup: Shows the potential state of maximizing space utilization.

I hope this concrete feedback from a frontline user can be helpful for the continuous improvement of VFB2. Thank you again to the team for always listening to user feedback and for creating excellent rendering tools.

Best regards,
[TFB]