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.

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.

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.

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.

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.

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

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.

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.