HiDPI support

[GarethH96]

I am struggling to see the icons on the toolbar and the paint on my 3840x2160 23 inch monitor:

The lines of the paint are more visible in the screen capture than they actually are. I am using Arch Linux with KDE Plasma. Issue is same with both Wayland and X11.

[RTimothyEdwards]

Put this in your .magicrc file ($HOME/.magicrc):

set Opts(scale) 2.0
set Opts(toolscale) 1.0

This does not entirely correct the problem but it does deal with the toolbar and menus. . . I think. It has been some time since I made some modifications to deal with the high resolution display on my laptop. It's possible that I made other changes locally that I would need to track down. Anyway, try the above options, and if they don't work as advertised, please let me know.

[mooredan]

I've noticed a similar display on a 4k monitor as well -- the grid is not well displayed, the fonts are tiny as is the pallete. The Xdefaults settings don't seem to help, but I did find a way to get the fonts bigger (I'll share that once I'm back home in front of my desktop computer).

[GarethH96]

@RTimothyEdwards

Put this in your .magicrc file ($HOME/.magicrc):

set Opts(scale) 2.0
set Opts(toolscale) 1.0

Tried that. It had no effect.

[RTimothyEdwards]

I looked back at my notes and saw that I wrote that the setting

Xft.dpi:  180

in the ~/.Xdefaults file appeared to correct the size of fonts for any application using Xft fonts, which includes Tk. I have a fairly low confidence that this is really a solution. I'm hoping that @mooredan can shed some more light on it.

I'm not sure why the "set Opts(scale)" doesn't work. If you start magic with the -rcfile option, then the file passed on the command line will prevent the home .magicrc file from being read; that's the only thing I can think of.

I had also found that the following works in ~/.magicrc to increase the size of fonts in the menus, which may be worth a try if the Xft.dpi resource doesn't work:

font create newfont -family helvetica -size 18
option add *Font newfont

[GarethH96]

@RTimothyEdwards

Xft.dpi:  180

in the ~/.Xdefaults file

Doesn't work.

I had also found that the following works in ~/.magicrc to increase the size of fonts in the menus, which may be worth a try if the Xft.dpi resource doesn't work:

font create newfont -family helvetica -size 18
option add *Font newfont

This increases the size of the top menu:

It works with and without using -rcfile ~/.magicrc. The toolbar icons are still tiny, though.

[mooredan]

The home directory .tkconrc file (~/.tkconrc) can be used to set the font in the "terminal" area of the tkcon window (among other things). Here is the contents of mine:

tkcon font Tahoma 12
set ::tkcon::OPT(history) 1000
set ::tkcon::OPT(showmenu) 0

[mooredan]

I can confirm that using "font ..." in the .magicrc file controls the layout window menu font size too. Thanks!

That leaves a couple of other aesthetic issues with a large display:

• the display of lines in the grid are not uniform
• the palette icons are small - would be better if larger
• the palette isn't wrapping when the layout window is resized smaller

[RTimothyEdwards]

Try the update I made today. Ii discovered that I can use the Tk "font measure" command to get the pixel size of the Tk default font, which scales with screen resolution, and use that to automatically adjust the glyph and icon sizes. Then there is no need to set a scale manually because the behavior should look more or less the same regardless of screen resolution. I still need to figure out if there is something I can do about the cursors, but those are handled by X11 and not Tk, so they don't have the scaling option that Tk has for the icon and glyph images (update is magic version 8.3.131).

[mooredan]

Traded in my MacBook Pro for a proper Linux laptop: a System76 Lemur Pro. It has a 1080p display and seeing the same fragmenting of the grid as seen on the larger desktop display:

[mooredan]

It seems like its the line style itself that has the issue. Not the solution, but trying figure out what's going on. If the line style is set to solid ( calling grtkSetLineStyle(0) in grtkDrawGrid), then the grid itself is OK. It's the setting of LineOnOffDash style in grtkSetLineStyle() that seems to make it look funny. ...and maybe what's being passed to XSetDashes()

[mooredan]

In file grTk1.c, function grtkSetLineStyle lines 180-232 -- What it is doing is that it appears to be setting things up for a call to XSetDashes if the passed style if not defined. The style isn't defined (how does one define it?) and the result is a linestyle->dashlist array with one element and that one element is set to 1.

Playing around with this value a bit, I found that a value of 4 produces a uniform grid looking like this:

So it looks like a solution is to be able to define the linestyle, or somehow detect the hi res display in this routine and adjust accordingly.

[RTimothyEdwards]

Well, the X11 graphics on 24 bits per pixel is a horrible graphics style and I never use it. Use OpenGL or Cairo. Then the grid is set to a solid line with alpha transparency, and everything else looks a lot better, too.

[mooredan]

Using -d OGL option on the command line makes the grid look much better. Thanks. How is Cairo invoked? ...I have it compiled in but it's not described on the man page.

Downside of OGL is now the palette is just a bunch of black boxes:

[mooredan]

...just guessed: -d CAIRO looks great -- I'll use that from here on out.

Next on the list is how to make the palette icons larger?

[RTimothyEdwards]

The reason that the icons come up invalid in OpenGL has a complicated history with nVidia and a security flaw. There is a compile option --enable-cairo-offscreen that will fix it by using Cairo graphics for the icons even when it uses OpenGL for the layout window. "-d XR" also works for enabling Cairo (Chi-Rho, get it? I didn't make that up; it's actually how the Cairo graphics package got its name (technically, it should be XP, but the original graphics library was XR, so I kept that name)).