On Sun, Jun 30, 2013 at 4:14 AM, Ton Roosendaal t...@blender.org wrote:
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.
I think I now understand what you meant about
On Sat, Jun 29, 2013 at 6:16 PM, Reuben Martin reube...@gmail.com wrote:
On Saturday, June 29, 2013 04:47:09 PM Brecht Van Lommel wrote:
It's not a reliable value to use, because it's not correctly reported
by many monitors, and does not actually correspond to the DPI assumed
by any other UI
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
Hi,
As I explained before, I made MacBook retina to work for HiDPI in the least
intrusive way for our code. But I also had to do it in a way it would work for
everyone.
That meant I had to make two things work independently:
- DPI scaling for UIs in general.
- Apple's HiDPI implementation
Hi,
I had a look at this some months ago. For Windows there is a system
DPI that you can configure as a user and there's an API to query it.
It does not do this OS X trick with the 2x pixel size and decoupled
desktop coordinates, all coordinates are in actual pixels. Here's the
info:
Hey Brecht,
Note sure if it would help, but on Linux for X dpi, perhaps these
options might be of help?:
Option UseEdidDpi FALSE
Option DPI 96x96
I need them in my xorg.conf here, but in my case, it is because my
monitor reports poor info. Anyways, just a side
It's not a reliable value to use, because it's not correctly reported
by many monitors, and does not actually correspond to the DPI assumed
by any other UI toolkit. I've looked for the right value for quite a
while, but only conclusion I can find is that none of
Gnome/KDE/Xfce/GTK/Qt/.. have
I think there are at least three topics worth discussing here..
(a) how should blender appear on a hidpi display, relative to a regular
display (either dual monitor, or when moving a blend file between machines)
(b) how should the Blender code achieve this..
(c) how is hidpi detected on
On Saturday, June 29, 2013 04:47:09 PM Brecht Van Lommel wrote:
It's not a reliable value to use, because it's not correctly reported
by many monitors, and does not actually correspond to the DPI assumed
by any other UI toolkit. I've looked for the right value for quite a
while, but only
Hi,
(a) how should blender appear on a hidpi display, relative to a regular
display (either dual monitor, or when moving a blend file between machines)
That's supported and working already even!
(b) how should the Blender code achieve this..
Given the fact every pixel in our UI is opengl
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
11 matches
Mail list logo
