[Bf-committers] DPI scaling question...

David Jeske davidj at gmail.com
Thu Jun 27 09:38:21 CEST 2013


On Thu, Jun 27, 2013 at 12:13 AM, Campbell Barton <ideasman42 at gmail.com>wrote:

> On Thu, Jun 27, 2013 at 4:53 PM, Campbell Barton <ideasman42 at gmail.com>
> wrote:
> > Noticed node placement bug this morning,
> > fixed r57813.
> >
> > 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?
>

I don't know what you mean here. Node placement from the right click menu
is supposed to occur at the cursor, but because the position is not
properly DPI scaled, it is often created offscreen on retina.


> this patch removes DPI scaling from the node space,
> http://www.graphicall.org/ftp/ideasman42/nodes_no_dpi_r57813.diff
>
> however I can see why its done now, without it a low DPI makes nodes
> smaller and further apart. :S
>

As far as I can see, in the current model of handling DPI, the new node
placement, node size and default spacing should be DPI scaled.

...which brings us back to my original question. Why is DPI exposed to so
much blender code? If there was a virtual coordinate system and DPI/PIXEL
scaling was hidden, then none of these places would know about DPI, node
placement would be right, and node spacing would be consistent.

Is this to avoid a wrapper around the GL calls for 2d operations? Does that
overhead matter? They could be inlined.


More information about the Bf-committers mailing list