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

[David Jeske]

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.