Re: [Bf-committers] HiDPI notes for other OS'es
On Sun, Jun 30, 2013 at 4:14 AM, Ton Roosendaal t...@blender.org wrote: The node editor has been badly patched indeed, which is solvable, but not so easy. I postponed it to wait for decisions or designs how we want the node editor to evolve. I think I now understand what you meant about combining 2d and the widgets in the node editor being a challenge for the current coordinate model. You mean because the nodes themselves have widgets drawn into their faces right? The bug you mention (for adding nodes) is just a python scripting issue - it tries to do DPI magic there, which it shouldn't. As far as I can see, the retina node-placement bug is not caused by Campbell's recent patch that added those DPI calculations. It existed before he added that, and is unaffected by it. If you take out those calculations the bug is still present and exactly the same. The bug exists because there is a pixelsize (not DPI) compensation issue -- this is why it happens only on retina. If I understand what's going on the node-editor 2d camera zoom and origin are not being scaled for pixelsize, which means mouse events must be scaled for pixelsize before being used as coordinates to places new nodes. I think this could be fixed in v2d.region_to_view, as you mentioned in your other email. I've moved onto some other stuff, but if this doesn't get fixed in a while I'll turn back to it. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
On Sat, Jun 29, 2013 at 6:16 PM, Reuben Martin reube...@gmail.com wrote: On Saturday, June 29, 2013 04:47:09 PM Brecht Van Lommel wrote: It's not a reliable value to use, because it's not correctly reported by many monitors, and does not actually correspond to the DPI assumed by any other UI toolkit. I've looked for the right value for quite a while, but only conclusion I can find is that none of Gnome/KDE/Xfce/GTK/Qt/.. have proper high DPI support on Linux/X11, it's just not implemented. If one of them did we could copy the same mechanism to detect DPI. Blog post from yesterday may provide insight into how others are tackling the issue. http://blogs.gnome.org/alexl/2013/06/28/hidpi-support-in-gnome/ Thanks for the link, good to see there is some effort underway to implement this natively, this is exactly the kind of thing that's needed. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
Hi David, I fully agree that a HiDPI screen visually should be 1:1 identical to regular layouts. The node editor has been badly patched indeed, which is solvable, but not so easy. I postponed it to wait for decisions or designs how we want the node editor to evolve. The main design exception is for how do draw images - if you work on a 4k screen you want zoom level '1' to be showing the full 4k frame. There's something to say for keeping it that way. The bug you mention (for adding nodes) is just a python scripting issue - it tries to do DPI magic there, which it shouldn't. So: if we solve the node problem, we're basically set. The fact blender's UI drawing has all kinds of bad patches is unrelated. It already was bad and the dpi code only exposes it more visibly. It can be cleaned up any time, but we don't have to do that for HiDPI support really. OSX Cocoa APIs pretty successfully hide these details from all code that doesn't care about them by using a virtual coordinate space Our interface drawing code (in C) I would consider as hide. The Python API should be totally DPI-free. I'm pretty sure Apple devs have been hacking a lot deep down in their code too. Using retina some programs still have glitches, even for apple programs :) -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 29 Jun, 2013, at 22:37, David Jeske wrote: Looking away from the details for a moment.. It would be helpful to have a clear Blender HiDPI philosophy, so we know the right way to fix these bugs... I'll take a shot at this now... If I understand your philosophy Ton, I think it is: 1) Editors where 2d pixels are not edited (everything except the uv-editor), should appear to be at the same zoom-level/origin when loaded on normal and high dpi displays. This means that a single blend file loaded on normal and high dpi would have 3dviews and node-editors positioned and zoomed to show roughly the same amount of stuff. Can we agree on #1? 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. Here is a second guidline to explain this... 2) Editors where 2d pixels can be directly edited (today just the uv-editor), should keep their data-to-screen-pixel ratio constant when loaded on normal and high dpi display. This means a uv-editor setup zoomed to take up most of the screen on high-dpi, would be 2-4x the screen size when loaded on normal dpi. My sensibilities say to drop #2 and make everything #1. However, I'm not an artist who paints on 2d uv-maps. It would be good to hear their opinion here. If #2 rule stays, it would be useful to know if this applies to scenerios where the uv-editor is used a results display, such as render/compositor results -- or only 2d image editing. We might also consider these possible guidelines: optional 3) Views showing 2d pixels have an obvious way to get to 1:1 mapping, and an obvious visual that they are in 1:1 mapping. optional 4) Views showing 2d pixels have zoom steps and/or snaps to make integer mappins easy to arrive at. I like #3 more than #4, though I can see arguments for each. After we get through the philosophy, we can apply it to the details 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. I see two related bugs in the node-editor which seem easy to fix, and I would like to fix... but I don't know the agreed way to fix them without the above HiDPI Philosophy. :) A) Node-editor shift-a node placement not aligned to mouse on Retina... http://projects.blender.org/tracker/index.php?func=detailaid=35920group_id=9atid=498 B) Node-editor content in a blend is zoomed different on retina vs normal... (this is a bug if we agree on HiDPI Philosophy point #1 above) Fixing B should automatically fix A. However, if B is not a bug, then the screen-to-nodespace coordinate transform for new node creation must be changed to adjust for pixelsize. This is in python and AFAIK python does not have access to pixelsize currently. 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. I agree that today the easiest solution to fix the node-editor bugs above is by adding a pixelsize adjustment in the right place, and I
[Bf-committers] HiDPI notes for other OS'es
Hi, As I explained before, I made MacBook retina to work for HiDPI in the least intrusive way for our code. But I also had to do it in a way it would work for everyone. That meant I had to make two things work independently: - DPI scaling for UIs in general. - Apple's HiDPI implementation Unfortunately these two features were not following an identical specification. That meant I had to seperate it in a Mac-only value (Pixelsize for now) and DPI. For example, a retins dot is default set to be two pixels large. If you start Blender with 72 DPI, it will show visually the same button sizes whether you are in retina mode or not. An important design decision from Apple was to decouple Desktop coordinates from pixels. You can have retina desktops of 1024, 1440, 1920 wide which all get mapped to the actual 2880 screen pixels. But for each desktop width, a dot and standard line widths stay 2 pixels. Still following? :) Mind boggling... especially if you draw the whole UI in OpenGL. I'm still waiting for information how Linux or Windows will address HiDPI. Hopefully in the same way, but probably not... -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
Hi, I had a look at this some months ago. For Windows there is a system DPI that you can configure as a user and there's an API to query it. It does not do this OS X trick with the 2x pixel size and decoupled desktop coordinates, all coordinates are in actual pixels. Here's the info: http://msdn.microsoft.com/en-us/library/windows/desktop/dd464660(v=vs.85).aspx There might be some unforeseen issues to solve but a Windows developer might be able to get this working quickly with just a few changes in the code. On Linux I don't know what the solution is, I couldn't even get any desktop environment configured to properly work on my MacBook Retina. Typically the advice seems to be to make the fonts bigger, and tweak some settings to make icons bigger, etc. But that alone doesn't make things look and work quite right, many things are still too small then and many applications don't follow these settings anyway. The problem for us is that there seems to be no standard system wide DPI setting that can be reliably used. Until there is a standard solution here I guess this will remain something that the user has to configure manually. Brecht. On Sat, Jun 29, 2013 at 2:22 PM, Ton Roosendaal t...@blender.org wrote: Hi, As I explained before, I made MacBook retina to work for HiDPI in the least intrusive way for our code. But I also had to do it in a way it would work for everyone. That meant I had to make two things work independently: - DPI scaling for UIs in general. - Apple's HiDPI implementation Unfortunately these two features were not following an identical specification. That meant I had to seperate it in a Mac-only value (Pixelsize for now) and DPI. For example, a retins dot is default set to be two pixels large. If you start Blender with 72 DPI, it will show visually the same button sizes whether you are in retina mode or not. An important design decision from Apple was to decouple Desktop coordinates from pixels. You can have retina desktops of 1024, 1440, 1920 wide which all get mapped to the actual 2880 screen pixels. But for each desktop width, a dot and standard line widths stay 2 pixels. Still following? :) Mind boggling... especially if you draw the whole UI in OpenGL. I'm still waiting for information how Linux or Windows will address HiDPI. Hopefully in the same way, but probably not... -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
Hey Brecht, Note sure if it would help, but on Linux for X dpi, perhaps these options might be of help?: Option UseEdidDpi FALSE Option DPI 96x96 I need them in my xorg.conf here, but in my case, it is because my monitor reports poor info. Anyways, just a side thought since you mentioned. o/ Dan On Sat, Jun 29, 2013 at 9:51 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Hi, I had a look at this some months ago. For Windows there is a system DPI that you can configure as a user and there's an API to query it. It does not do this OS X trick with the 2x pixel size and decoupled desktop coordinates, all coordinates are in actual pixels. Here's the info: http://msdn.microsoft.com/en-us/library/windows/desktop/dd464660(v=vs.85).aspx There might be some unforeseen issues to solve but a Windows developer might be able to get this working quickly with just a few changes in the code. On Linux I don't know what the solution is, I couldn't even get any desktop environment configured to properly work on my MacBook Retina. Typically the advice seems to be to make the fonts bigger, and tweak some settings to make icons bigger, etc. But that alone doesn't make things look and work quite right, many things are still too small then and many applications don't follow these settings anyway. The problem for us is that there seems to be no standard system wide DPI setting that can be reliably used. Until there is a standard solution here I guess this will remain something that the user has to configure manually. Brecht. On Sat, Jun 29, 2013 at 2:22 PM, Ton Roosendaal t...@blender.org wrote: Hi, As I explained before, I made MacBook retina to work for HiDPI in the least intrusive way for our code. But I also had to do it in a way it would work for everyone. That meant I had to make two things work independently: - DPI scaling for UIs in general. - Apple's HiDPI implementation Unfortunately these two features were not following an identical specification. That meant I had to seperate it in a Mac-only value (Pixelsize for now) and DPI. For example, a retins dot is default set to be two pixels large. If you start Blender with 72 DPI, it will show visually the same button sizes whether you are in retina mode or not. An important design decision from Apple was to decouple Desktop coordinates from pixels. You can have retina desktops of 1024, 1440, 1920 wide which all get mapped to the actual 2880 screen pixels. But for each desktop width, a dot and standard line widths stay 2 pixels. Still following? :) Mind boggling... especially if you draw the whole UI in OpenGL. I'm still waiting for information how Linux or Windows will address HiDPI. Hopefully in the same way, but probably not... -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
It's not a reliable value to use, because it's not correctly reported by many monitors, and does not actually correspond to the DPI assumed by any other UI toolkit. I've looked for the right value for quite a while, but only conclusion I can find is that none of Gnome/KDE/Xfce/GTK/Qt/.. have proper high DPI support on Linux/X11, it's just not implemented. If one of them did we could copy the same mechanism to detect DPI. On Sat, Jun 29, 2013 at 4:32 PM, Dan McGrath danmcgrath...@gmail.com wrote: Hey Brecht, Note sure if it would help, but on Linux for X dpi, perhaps these options might be of help?: Option UseEdidDpi FALSE Option DPI 96x96 I need them in my xorg.conf here, but in my case, it is because my monitor reports poor info. Anyways, just a side thought since you mentioned. o/ Dan On Sat, Jun 29, 2013 at 9:51 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Hi, I had a look at this some months ago. For Windows there is a system DPI that you can configure as a user and there's an API to query it. It does not do this OS X trick with the 2x pixel size and decoupled desktop coordinates, all coordinates are in actual pixels. Here's the info: http://msdn.microsoft.com/en-us/library/windows/desktop/dd464660(v=vs.85).aspx There might be some unforeseen issues to solve but a Windows developer might be able to get this working quickly with just a few changes in the code. On Linux I don't know what the solution is, I couldn't even get any desktop environment configured to properly work on my MacBook Retina. Typically the advice seems to be to make the fonts bigger, and tweak some settings to make icons bigger, etc. But that alone doesn't make things look and work quite right, many things are still too small then and many applications don't follow these settings anyway. The problem for us is that there seems to be no standard system wide DPI setting that can be reliably used. Until there is a standard solution here I guess this will remain something that the user has to configure manually. Brecht. On Sat, Jun 29, 2013 at 2:22 PM, Ton Roosendaal t...@blender.org wrote: Hi, As I explained before, I made MacBook retina to work for HiDPI in the least intrusive way for our code. But I also had to do it in a way it would work for everyone. That meant I had to make two things work independently: - DPI scaling for UIs in general. - Apple's HiDPI implementation Unfortunately these two features were not following an identical specification. That meant I had to seperate it in a Mac-only value (Pixelsize for now) and DPI. For example, a retins dot is default set to be two pixels large. If you start Blender with 72 DPI, it will show visually the same button sizes whether you are in retina mode or not. An important design decision from Apple was to decouple Desktop coordinates from pixels. You can have retina desktops of 1024, 1440, 1920 wide which all get mapped to the actual 2880 screen pixels. But for each desktop width, a dot and standard line widths stay 2 pixels. Still following? :) Mind boggling... especially if you draw the whole UI in OpenGL. I'm still waiting for information how Linux or Windows will address HiDPI. Hopefully in the same way, but probably not... -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
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
Re: [Bf-committers] HiDPI notes for other OS'es
On Saturday, June 29, 2013 04:47:09 PM Brecht Van Lommel wrote: It's not a reliable value to use, because it's not correctly reported by many monitors, and does not actually correspond to the DPI assumed by any other UI toolkit. I've looked for the right value for quite a while, but only conclusion I can find is that none of Gnome/KDE/Xfce/GTK/Qt/.. have proper high DPI support on Linux/X11, it's just not implemented. If one of them did we could copy the same mechanism to detect DPI. Blog post from yesterday may provide insight into how others are tackling the issue. http://blogs.gnome.org/alexl/2013/06/28/hidpi-support-in-gnome/ -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
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 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...
Re: [Bf-committers] HiDPI notes for other OS'es
Looking away from the details for a moment.. It would be helpful to have a clear Blender HiDPI philosophy, so we know the right way to fix these bugs... I'll take a shot at this now... If I understand your philosophy Ton, I think it is: 1) Editors where 2d pixels are not edited (everything except the uv-editor), should appear to be at the same zoom-level/origin when loaded on normal and high dpi displays. This means that a single blend file loaded on normal and high dpi would have 3dviews and node-editors positioned and zoomed to show roughly the same amount of stuff. Can we agree on #1? 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. Here is a second guidline to explain this... 2) Editors where 2d pixels can be directly edited (today just the uv-editor), should keep their data-to-screen-pixel ratio constant when loaded on normal and high dpi display. This means a uv-editor setup zoomed to take up most of the screen on high-dpi, would be 2-4x the screen size when loaded on normal dpi. My sensibilities say to drop #2 and make everything #1. However, I'm not an artist who paints on 2d uv-maps. It would be good to hear their opinion here. If #2 rule stays, it would be useful to know if this applies to scenerios where the uv-editor is used a results display, such as render/compositor results -- or only 2d image editing. We might also consider these possible guidelines: optional 3) Views showing 2d pixels have an obvious way to get to 1:1 mapping, and an obvious visual that they are in 1:1 mapping. optional 4) Views showing 2d pixels have zoom steps and/or snaps to make integer mappins easy to arrive at. I like #3 more than #4, though I can see arguments for each. After we get through the philosophy, we can apply it to the details 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. I see two related bugs in the node-editor which seem easy to fix, and I would like to fix... but I don't know the agreed way to fix them without the above HiDPI Philosophy. :) A) Node-editor shift-a node placement not aligned to mouse on Retina... http://projects.blender.org/tracker/index.php?func=detailaid=35920group_id=9atid=498 B) Node-editor content in a blend is zoomed different on retina vs normal... (this is a bug if we agree on HiDPI Philosophy point #1 above) Fixing B should automatically fix A. However, if B is not a bug, then the screen-to-nodespace coordinate transform for new node creation must be changed to adjust for pixelsize. This is in python and AFAIK python does not have access to pixelsize currently. 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. I agree that today the easiest solution to fix the node-editor bugs above is by adding a pixelsize adjustment in the right place, and I plan to do it myself. It is also easy to manually fix other similar bugs, and teach every future blender UI coder to properly use DPI and pixelsize in their screen-to-editor transforms. However, in continuing to choose the short term easy route, we are creating needless complexity, where unncessary amounts of code have to deal with DPI and pixelsize. I don't believe there is anything inevitable about having all drawing code know about DPI and pixelsize. OSX Cocoa APIs pretty successfully hide these details from all code that doesn't care about them by using a virtual coordinate space. AFAIK, it's an easy but larger refactor to abstract DPI and pixelsize behind drawing and drawing-setup abstractions -- freeign future programmers from having to think about it. Rather than debating what is possible though, perhaps I can rephrase this as a more practical question When might be a good time to consider such a large-but-easy refactor patch, given GSOC branch merging and other such things? I'd personally like to make this patch and show how it would work, but there is no hurry, as it's going to be a while before I understand blender code enough anyhow. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
