[Bf-committers] HiDPI notes for other OS'es

[Ton Roosendaal]

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  -  ton at 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=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
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers