[Bf-committers] DPI scaling question...

[David Jeske]

On Wed, Jun 26, 2013 at 11:53 PM, Campbell Barton <ideasman42 at gmail.com>wrote:

> Noticed node placement bug this morning,
> fixed r57813.
>

Unfortunately, r57813 did not fix the node-placement bug on retina, because
the retina bug is related to U.pixelsize ... (see below)

Though IMHO using DPI to coords for node placement isn't a good idea
> (anything besides drawing), but perhaps theres a good reason for it?


My instinct, like Brecht, is that DPI and pixelsize shouldn't be seen by
most of the C code, and certainly not Python... only coordinate-space
transformations, 2d drawing primitives, and a couple places that need to
care about pixels. For example, the code currently has lines like:

  BLF_size(fontid, <font point size> * U.pixelsize, U.dpi);

Which IMO should be changed to hide the DPI and PIXELSIZE inside the
abstraction:

 BLF_size(fontid, <font point size>);

Today, however, this is not how the code handles DPI and PIXELSIZE scaling.
I'm guessing we should wait until Ton has the time to tell us if there is a
good reason it's done the current way before looking at this bigger
picture...

In the meantime, I did some digging and I don't think the retina
node-placement location bug is related to pixelsize mouse-transforms. I
think it's related to drawing code that does not handle pixelsize.

Some 2d viewers, including the node editor, do not seem to be handling
pixelsize in their local offset and zoom transforms. You can see this
because if you drag blender from a retina to non-retina display, these
viewers suddenly appear to be at a different zoom level (node, uv-edit,
logic,  This is fine when transforms are relative. However, when the
coordinate is absolute in the view-space, it doesn't align with the drawing
coordinates which have not been adjusted for pixelsize.

..at least this is what I think is going on. It's going to take a little
more digging to be sure. I think i'll leave this bug until I've fixed some
simpler stuff.