On Retina displays : node-editor shift-a node creation does not create the node in the right place... #35920

New Issue

David Jeske · 2013-06-29T20:51:15+02:00

David Jeske commented

2013-06-29 20:51:15 +02:00

%%%--- Operating System, Graphics card ---

Macbook Pro Retina (and other HiDPI retina displays, when they exist)

- Blender version with error, and version that worked ---

broken in 2.67b and all previous versions

- Short description of error ---

Node editor new nodes created in the wrong place on Macbook Pro Retina.

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

Open the node-editor on a Macbook Pro Retina display
use the shift-a menu to add a node
WITNESS: the new node is created in the wrong place

I've done some digging into this bug, and it seems to be caused by the fact that uv-editor and node-editor (which share the grid drawing code) do not adjust their drawing for U.pixelsize. This causes the mouse event (x,y) coordinates to be transformed to the wrong place on the node-editor canvas when U.pixelsize is not 1.0. Not sure what the right fix is though.
%%%

%%%--- Operating System, Graphics card --- Macbook Pro Retina (and other HiDPI retina displays, when they exist) - Blender version with error, and version that worked --- broken in 2.67b and all previous versions - Short description of error --- Node editor new nodes created in the wrong place on Macbook Pro Retina. - Steps for others to reproduce the error (preferably based on attached .blend file) --- 1. Open the node-editor on a Macbook Pro Retina display 2. use the shift-a menu to add a node 3. WITNESS: the new node is created in the wrong place ----------- I've done some digging into this bug, and it seems to be caused by the fact that uv-editor and node-editor (which share the grid drawing code) do not adjust their drawing for U.pixelsize. This causes the mouse event (x,y) coordinates to be transformed to the wrong place on the node-editor canvas when U.pixelsize is not 1.0. Not sure what the right fix is though. %%%

David Jeske commented

2013-06-29 20:51:15 +02:00

Changed status to: 'Open'

Campbell Barton commented

2013-06-30 23:58:29 +02:00

%%%Reverted my initial fix which checked DPI factor but not pixelsize,
had a look into this and think it would be best if SpaceNode.cursor stored UI_view2d_region_to_view only, and the node editor can scale the value how it likes when using.

That, or the value could be scaled on RNA access.%%%

%%%Reverted my initial fix which checked DPI factor but not pixelsize, had a look into this and think it would be best if SpaceNode.cursor stored UI_view2d_region_to_view only, and the node editor can scale the value how it likes when using. That, or the value could be scaled on RNA access.%%%

Claudio D. commented

2013-07-11 05:45:30 +02:00

%%%I dont mean to be rude or annoying, but please, give this a second view. This is a very annoying thing to deal with, it is not only time consuming but also discouraging when working on large tree nodes. I wish I could help. Thank you so much to whoever takes the time.%%%

Campbell Barton commented

2013-07-11 07:21:28 +02:00

%%%Claudio D. We know this is really a bad problem, just not many devs have OSX+Retina displays to test with.

I have a patch that works on linux to make the display show non 1.0 Pixelsizes but Im not certain that the mouse coordinates are handled the same way.%%%

%%%Claudio D. We know this is really a bad problem, just not many devs have OSX+Retina displays to test with. I have a patch that works on linux to make the display show non 1.0 Pixelsizes but Im not certain that the mouse coordinates are handled the same way.%%%

David Jeske commented

2013-07-11 07:31:46 +02:00

%%%I'm going to take another look at this in a couple days. This was actually the very first coding/bug I tried to work on in blender, and it turned out to be just a bit too deeply buried in coordinate transformation and dpi handling choices.

I think I better understand what is "wrong" with it now, so I'll take another look. %%%

%%%I'm going to take another look at this in a couple days. This was actually the very first coding/bug I tried to work on in blender, and it turned out to be just a bit too deeply buried in coordinate transformation and dpi handling choices. I think I better understand what is "wrong" with it now, so I'll take another look. %%%

Ton Roosendaal commented

2013-07-17 12:06:28 +02:00

%%%Both me and Brecht have checked it (for hours), and it's going to be not a very trivial fix. Too risky to rush in before 2.68, so it gets moved to next release.%%%

Campbell Barton commented

2013-07-17 12:49:11 +02:00

%%%re-committed temp workaround. noted as not real fix but at least it works on all non retina displays with non-default DPI.%%%

David Jeske commented

2013-07-17 20:59:01 +02:00

%%%For when this is fixed...

After looking at the issue, I think a part of the solution is for node-space zoom to adjust for pixelsize -- making the outliner objects appear the same size on screen for retina and non-retina at the same zoom level. This is both consistent with the Apple recommended way of handling retina, and much more sane in the face of many different DPI displays, including upcoming UltraHD.

I know there is concern about how this affects UV-editor and images, and what 1:1 mapping means in the image editor. I think in most practical situations it will be best if a given view-transform zoom-level (in memory or saved in a file) is adjusted for pixelsize, such that it appears the same physical size in inches when loaded or moved between displays. The "1:1" menu option should achieve 1:1 pixel mapping, and to do this, it will need to adjust for pixelsize and set the proper view-transform zoom-level based on the current display DPI. This means that a window is shown on a display with a different DPI (dragging or save/load), it will no longer be shown 1:1: Reselecting the 1:1 menu option on that display will reset it to 1:1 for that display. Also it may be useful to add a widget to the UV viewport which shows the current ratio of UV image pixels to raw-display pixels, to make this clear.

the truth is that DPI scailng introduces a virtual coordinate system where it is both inconvenient and difficult to try to achieve 1:1 mapping. For example, if a user today selects different Retina scaling modes, it adjusts the virtual "pixelsize" even while physical screen pixels remain the same.

%%%

%%%For when this is fixed... After looking at the issue, I think a part of the solution is for node-space zoom to adjust for pixelsize -- making the outliner objects appear the same size on screen for retina and non-retina at the same zoom level. This is both consistent with the Apple recommended way of handling retina, and much more sane in the face of many different DPI displays, including upcoming UltraHD. I know there is concern about how this affects UV-editor and images, and what 1:1 mapping means in the image editor. I think in most practical situations it will be best if a given view-transform zoom-level (in memory or saved in a file) is adjusted for pixelsize, such that it appears the same physical size in inches when loaded or moved between displays. The "1:1" menu option should achieve 1:1 pixel mapping, and to do this, it will need to adjust for pixelsize and set the proper view-transform zoom-level based on the current display DPI. This means that a window is shown on a display with a different DPI (dragging or save/load), it will no longer be shown 1:1: Reselecting the 1:1 menu option on that display will reset it to 1:1 for that display. Also it may be useful to add a widget to the UV viewport which shows the current ratio of UV image pixels to raw-display pixels, to make this clear. the truth is that DPI scailng introduces a virtual coordinate system where it is both inconvenient and difficult to try to achieve 1:1 mapping. For example, if a user today selects different Retina scaling modes, it adjusts the virtual "pixelsize" even while physical screen pixels remain the same. %%%

Ton Roosendaal commented

2013-09-05 14:53:06 +02:00

%%%Fix for adding nodes in retina is now in svn
Code also cleans up some of the ugly 'cursor' code in node system.

The generic issues with how to handle high-dpi screens properly will need to be revisited later. I would prefer to gather information for how Windows/Linux or even Android handles this now. Once some more developers have high-dpi themselves it will be an easier topic to revisit too.%%%

%%%Fix for adding nodes in retina is now in svn Code also cleans up some of the ugly 'cursor' code in node system. The generic issues with how to handle high-dpi screens properly will need to be revisited later. I would prefer to gather information for how Windows/Linux or even Android handles this now. Once some more developers have high-dpi themselves it will be an easier topic to revisit too.%%%

Ton Roosendaal commented

2013-09-05 14:53:07 +02:00

Changed status from 'Open' to: 'Resolved'

Ton Roosendaal closed this issue

2013-09-05 14:53:07 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

On Retina displays : node-editor shift-a node creation does not create the node in the right place... #35920