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 <t...@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@blender.org http://lists.blender.org/mailman/listinfo/bf-committers