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=detail&aid=35920&group_id=9&atid=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 [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
