Cocoa_Window and retina support

jelle's picture

Hi,

I've noticed that the Cocoa_Window does not support retina / Hi-DPI screen ( like you find on a mac book pro or an android or iOS device ).

Cocoa is conservative and won't go into retina mode, unless NSView's setViewWantsBestResolutionOpenGLSurface( true) method is called.

There is a pretty decent post on the WX forum [1] that also show how to bind to events ( relevant when moving a screen from a normal resolution screen to a retina resolution screen )

It would be great if Cocoa_Window can support this.

-jelle

[1] https://forums.wxwidgets.org/viewtopic.php?f=20&t=36684

kgv's picture

Re: Cocoa_Window

Hi,

first of all, I would like to describe what Cocoa_Window is.
Classes Cocoa_Window/WNT_Window/Xw_Window are designed to wrap native window definition to OpenGL layer. That is - just to create and manage OpenGL context. No abstraction to handle window messages and so on.

There are two constructors in these classes:
- First takes handle to existing native window created by application using GUI framework. This method is actually used by most applications.
- Second just creates new window. This method mostly exists to simplify viewer creation in Draw Harness.

Curiously Cocoa is already high-level GUI framework (while on other systems most applications have to use Qt, WinForms, MFC, Wx and other stuff), thus on OS X the second constructor looks almost self-sufficient. Though it is still expected that application would create NSView and manage required parameters appropriately by itself (like dpi-awareness calling setWantsBestResolutionOpenGLSurface method).

Concerning dpi-awareness - in fact Visualization layer in OCCT is currently dpi-unaware. While shaded presentation in 3D-viewer does not require any modifications, other parts should be considered:
- Line width should be scaled for wireframe presentation.
- Markers should be scaled.
- Fixed-size text labels should be scaled as well.
- GUI elements which might be drawn using 2D Overlayer/Underlayer functionality should be scaled.
Moreover, for better experience on systems with multiple displays, this scaling should be adjusted depending on monitor where window is currently placed on.

And this is true not only for Retina displays on OS X, but on Windows (see also APIs introduced in Windows 8.1) and Android as well.

That means that application should really care about these problems, and setting dpi-awareness implicitly from Cocoa_Window would be lying and might lead to bad user experience. I was very frustrated when first seen how many applications on Windows support dpi-settings incorrectly - and it would be better if these application would be scaled by system instead (leading to poor visual quality though, but at least with proper layout).

So, I would consider adding constructor parameter to Cocoa_Window to declare dpi-awareness, set to false by default.

I'm not sure if it would be a good idea to provide global dpi-scaling ratio for V3d_View, thus dpi-aware application might set it and OCCT would manage scaling automatically within 3D viewer in most cases. But probably such option would make adoption easier and more natural.

jelle's picture

thanks for the detailed

thanks for the detailed reply.

so, true, this is a general concern.
and thanks for pointing out that the issue is more complex than merely doubling the OpenGL resolution.

providing a global dpi-scaling in V3d_View would be a very welcome addition.
this way, the application can react on events ( such as you mention moving from a hi-dpi to a conventional monitor ) and it would serve as a logical API call to manage hi-dpi resolution on any platform...

thanks again for the valuable feedback.

shall I go ahead and open an issue for providing a global dpi-scaling method?

kgv's picture

shall I go ahead and open an

shall I go ahead and open an issue for providing a global dpi-scaling method?

Yes, you are welcome to register new features.

www.opencascade.com

Copyright 2011-2019
OPEN CASCADE SAS
Contact us