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

[Ton Roosendaal]

Hi,

> (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)

That's supported and working already even!

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

Given the fact every pixel in our UI is opengl code, it's inevitable that there's local conversions needed for UI items in views. In general this goes it very nice - when code itself is nice and using opengl correctly - and messy in parts only when hardcoded values are used.

The remainder bugs for HiDPI are mainly because hardly anyone is using it yet :)
Each reported issue is really an easy fix.

For image drawing... we can check on it. I just wasn't sure if you want to have "zoom level 1" defined as 2 pixels for image pixels... that would be annoying I think. When 4k arrives on the desktop (during next years) we can figure out better. My experience with 4k production however is that you really want to see images as 1 pixel = 1 display pixel.

Not an easy fix in Blender is when 2d view transforms (like nodes) are used together with UI widget drawing. I kept this open, knowing node UI future is a todo item in general.

> 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?

Apple achieves HiDPI only via their own widget and Cocoa APIs. I think Blender is the first of non-Cocoa apps in Mac supporting this even. We could do this thanks to OpenGL, which is already using coordinate systems for all UI items. This is also why the "DPI" features works so well, and why you can zoom in/out for UI elements.

When 4k systems arrive on desktops for other OSes, they probably would just keep "1 desktop pixel" to stay "1 display pixel". For these situations we can simply allow a user to set pixel size to 2, so you get nice lines and 'dot' units and buttons draw accordingly. We don't need to use the desktop coordinate system mapping from Apple then.

-Ton-

> 
> (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...
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers