[Bf-committers] HiDPI notes for other OS'es

David Jeske davidj at gmail.com
Sat Jun 29 17:51:59 CEST 2013


I think there are at least three topics worth discussing here..

(a) how should blender "appear" on a hidpi display, relative to a regular
display (either dual monitor, or when moving a blend file between machines)

(b) how should the Blender code achieve this..

(c) how is hidpi detected on different systems.

----

first (a)... how should blender appear on hidpi?

On Sat, Jun 29, 2013 at 5:22 AM, Ton Roosendaal <ton at blender.org> wrote:
>
> ...it will show visually the same button sizes whether you are in retina
> mode or not.
>

I think this is the right behavior. Also, when a users has blender visible
on both retina and non-retina displays, those UI should "appear" the same
size. This requires HiDPI support to use something like the per-surface
"pixelsize" instead of the the user-preference "dpi" setting... so the
current strategy makes sense in that regard. (though the user-preference
might be better named "ui-scaling", since it really isn't strictly dpi)

now (b)...how should the code achieve this?...

Today there are bugs in this hidpi/pixelsize behavior, and I believe this
is in large part because of how exposed dpi/pixelsize are to drawing/input
code. For example, node-editor and uv-editor do not "appear" the same size
on retina and non-retina at the same local-zoom, because the current zoom
is not translated for pixelsize. This seems to be the source of another
retina bug, where adding a node using the context menu causes it to appear
at the wrong place on hidpi.

Ton - Do you have any long-term opposition to the code encapsulating
pixelsize (hidpi) and dpi (aka ui scaling) issues at a lower-level -- by
introducing a virtual coordinate system for blender, much like apple has a
virtual coordinate system? This would require changes to 2d drawing code,
as well as 3d view projection setup functions.. but as a benefit would free
(most) other code from dealing with DPI / pixelsize.

I don't know enough to attempt this change now, and it may not be the right
time to do it, since it would make ui-code merges more difficult. However,
I would like to know what you think about it.

In the short-term, it may be easier to fix both the uv-editor and
node-editor to use the current pattern and properly use pixelsize / DPI to
"appear" the same on retina and non-retina.

finally (c)...how is hidpi detected on different systems, and different
monitors on the same system

On Mac, the system gives you the pixelsize for a display surface, and it
seems to "magically" deal with windows spanning multiple surfaces, by
telling you one surface DPI and automatically scaling the content for the
other display.

On Linux, there are multiple ways to achieve multi-monitor. Last time I
looked, the most common method was using a dual-headed graphics card with a
"super big" coordinate space that looks like a single big monitor. I don't
think this can support heterogeneous normal/hi-dpi. Xinerama might be able
to.

AFAIK, Windows still hasn't fully figured out their HiDPI API strategy. I
suspect a hetrogenius normal/hi-dpi setup in windows would be problematic
today...


More information about the Bf-committers mailing list