Add native High-DPI support about solvespace

[Evil-Spirit]

@whitequark, we can render any resolution and technique we want if it has TTF version.

[DougBeney]

Just in case this helps anyone, if you're a Linux user, you can use the program run_scaled, to get this program working at proper scale on a HiDPI display.

Even though it's meant for xorg desktops, it works just fine for me on Wayland. Only caveat is that there is going to be a bit of a display lag. Better than nothing though, right?

[whitequark]

SolveSpace now has native HiDPI support on all platforms. Icon scaling will be added once someone contributes hi-res icons.

[ctag]

For anyone else who sees this thread and finds hidpi to still "not work", this may help:

$ GDK_SCALE=2 solvespace

Unfortunately fractional scaling (GDK_SCALE=0.75) doesn't seem to work with this approach, so the text is larger than comfortable, but at least readable.

[whitequark]

To fully fix this someone would have to redraw all the toolbar icons at 2x resolution. As I don't know anyone willing to do it, there's no ETA for that. If someone provides the icons I will implement the rest (which is simple after some recent changes).

[virtualritz]

I am happy to do that. I will do SVG versions of the icons. The PNGs can be rendered from those on the fly at any desired resolution, as part of the build.

[virtualritz]

Also note that this is not a requirement. It is better to have the icons scaled and the viewport at retina res than keeping it scaled just because the icons are not there. That's the approach most apps take that have icon dependencies. E.g. Qt Creator was retina capable long before they updated the icons.

[whitequark]

It is better to have the icons scaled and the viewport at retina res than keeping it scaled just because the icons are not there.

Correct. However, until recently, the code was structured such that all icon placement, text rendering, and so on was done in absolute coordinates, and not in a way that would have easily let me use two sets of them. Now it's better, and also I've recently added support for asset loading.

I am happy to do that. I will do SVG versions of the icons. The PNGs can be rendered from those on the fly at any desired resolution, as part of the build.

Thanks! That works for me. We can probably just check .png's into the source to avoid multiplying external dependencies that almost no one will need (e.g. imagemagick is a nightmare on Windows).

The context is that I have recently got rid of all generation during build to simplify cross-compilation, mostly by making loading the in-tree format much faster and then moving the loading into runtime. This is unfortunately not an option for SVGs without fairly heavy dependencies and runtime penalty.

[Evil-Spirit]

The icons can be rather simple. So, it can be drawn with solvespace itself)

[Evil-Spirit]

[whitequark]

The icons need to be aligned to the pixel grid during PNG export, which isn't quite that simple.

[virtualritz]

I'm using Inkscape for the icons. I'm new to solvespace so doing it in that app (while appealing) would eat too much time for me now. I can't even figure out how to change the radius of a circle after creating it. :)
Aligning to a pixel grid is easy in Inkscape too.

[virtualritz]

Here are some samples. Let me know if this is going in the right direction. I am trying to align everything on a pixel grid so it looks as crisp as possible at 24 pixel size and any even multiplier of that.

[virtualritz]

Colors are named, I'll extract them to a separate definitions SVG that the individual icon SVGs will reference. Changing colors and stroke widths in that file will then allow changing the look of all icons at once.

Here is an example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->

<svg
   xmlns:osb="http://www.openswatchbook.org/uri/2009/osb"
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://creativecommons.org/ns#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:xlink="http://www.w3.org/1999/xlink"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   width="48"
   height="48"
   viewBox="0 0 48 48"
   id="svg2"
   version="1.1"
   inkscape:version="0.91+devel+osxmenu r12922"
   sodipodi:docname="circle.svg">
  <defs
     id="defs">
    <linearGradient
       id="handle_fill"
       osb:paint="solid">
      <stop
         style="stop-color:#c0c0c0;stop-opacity:1;"
         id="stop1" />
    </linearGradient>
    <linearGradient
       id="handle_stroke"
       osb:paint="solid">
      <stop
         style="stop-color:#00ff00;stop-opacity:1;"
         id="stop2" />
    </linearGradient>
    <linearGradient
       id="line"
       osb:paint="solid">
      <stop
         style="stop-color:#c0c0c0;stop-opacity:1;"
         id="stop3" />
    </linearGradient>
  </defs>
  <sodipodi:namedview
     id="base"
     pagecolor="#000000"
     bordercolor="#666666"
     borderopacity="1.0"
     inkscape:pageopacity="0"
     inkscape:pageshadow="2"
     inkscape:zoom="15.999999"
     inkscape:cx="21.123213"
     inkscape:cy="23.614289"
     inkscape:document-units="px"
     inkscape:current-layer="layer1"
     showgrid="true"
     units="px"
     inkscape:snap-grids="true"
     inkscape:snap-smooth-nodes="false"
     inkscape:snap-intersection-paths="false"
     inkscape:object-paths="false"
     inkscape:snap-page="false"
     inkscape:object-nodes="true"
     inkscape:window-width="1680"
     inkscape:window-height="1005"
     inkscape:window-x="0"
     inkscape:window-y="23"
     inkscape:window-maximized="0"
     scale-x="1"
     scale-y="1">
    <inkscape:grid
       type="xygrid"
       id="grid8146"
       empspacing="2"
       spacingx="2"
       spacingy="2"
       dotted="false"
       units="px"
       snapvisiblegridlinesonly="false" />
  </sodipodi:namedview>
  <metadata
     id="metadata">
    <rdf:RDF>
      <cc:Work
         rdf:about="">
        <dc:format>image/svg+xml</dc:format>
        <dc:type
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
        <dc:title></dc:title>
        <cc:license
           rdf:resource="http://creativecommons.org/licenses/by-nc-sa/4.0/" />
      </cc:Work>
      <cc:License
         rdf:about="http://creativecommons.org/licenses/by-nc-sa/4.0/">
        <cc:permits
           rdf:resource="http://creativecommons.org/ns#Reproduction" />
        <cc:permits
           rdf:resource="http://creativecommons.org/ns#Distribution" />
        <cc:requires
           rdf:resource="http://creativecommons.org/ns#Notice" />
        <cc:requires
           rdf:resource="http://creativecommons.org/ns#Attribution" />
        <cc:prohibits
           rdf:resource="http://creativecommons.org/ns#CommercialUse" />
        <cc:permits
           rdf:resource="http://creativecommons.org/ns#DerivativeWorks" />
        <cc:requires
           rdf:resource="http://creativecommons.org/ns#ShareAlike" />
      </cc:License>
    </rdf:RDF>
  </metadata>
  <g
     inkscape:label="Layer"
     inkscape:groupmode="layer"
     id="layer"
     transform="translate(0,0)">
    <circle
       style="fill:none;fill-opacity:1;stroke:url(#line);stroke-width:2;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
       id="circle"
       cx="24"
       cy="24"
       r="18" />
    <rect
       style="fill:url(#handle_fill);fill-opacity:1;stroke:url(#handle_stroke);stroke-width:2;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
       id="handle1"
       width="6"
       height="6"
       x="21"
       y="21" />
  </g>
</svg>

[whitequark]

Let me know if this is going in the right direction.

I would aim for exactly representing the current items at 24x24. It doesn't have to be pixel-perfect but the dots inside rectangular points are, I think, excessive.

[virtualritz]

The dots can be removed by just setting handle_fill equal to handle_stroke color. I'll do that for now.

[valpackett]

It's not just macOS... The situation on Windows with a HiDPI screen isn't perfect too. It's possible to turn off blurry scaling (right click → properties → compatibility), but then the UI text becomes a bit too small.

Blender has the best UI scaling ever, just a DPI slider:

Adjusting at least the text size in solvespace would be great.

[whitequark]

Adjusting at least the text size in solvespace would be great.

The problem is that Unifont, which we use, is available in 16x16 and that's it. I can scale it 2x I guess.

[whitequark]

You can adjust the font used for constraints and edit boxes though, that works.

[whitequark]

@myfreeweb Anyway, yeah, I know about Windows HiDPI issues. Do you have any idea how to test this with Windows in a VM?

[virtualritz]

What's the problem with switching to another font? Particularly a non-bitmap font which would be nice. :)

[whitequark]

First, we would need:

• a TrueType font
• that can be distributed combined with a GPLv3 program
• with an excellent Unicode coverage, including CJK (Unifont has nearly 100% coverage of Unicode)

After that it's a matter of rewriting the text window rendering code, which is kind of gnarly.

[virtualritz]

FortAwesome/Font-Awesome#1124

[whitequark]

Font Awesome is a full suite of 634 pictographic icons for easy scalable vector graphics on websites

How is this relevant in any way?

[virtualritz]

The discussion is about compatibility of OFL and GPL. They seem to be compatible. If that were true, we could simply pick any font under the OFL.

[whitequark]

I see. The problem is that there are very few free monospace fonts with CJK support. In fact I could only find Noto (Droid Sans also has CJK support, but not in monospace, I think). On top of that the all-in-one Noto package is ~89MB archived, as opposed to the current Unifont situation, which is 700KB archived.

[whitequark]

For now, I feel that the following HiDPI support would be sufficient:

• All entities in the graphics window would be smoothly scaled according to the device scale factor.
• Icons in the graphics window, and the text window, would remain at 1x if device scale factor is less than 1.5, and at 2x if the device scale factor is more than 1.5. (Could be 1.75 here, I think whatever number Windows uses is the right one.)

Smoothly scaling SVGs at small icon sizes tends to produce ugliness; it is much better to pre-render them at known sizes (and perhaps manually hint). Smoothly scaling the (what replaces) bitmap font is perhaps more desirable, but is a lot of work, and is the bitmap font, at a readable size, really all that ugly?

[virtualritz]

Two thoughts:

1. If I need CJK support, I probably won't mind downloading a larger app. And if I don't need it, I can download a 'light' version of solvespace. The build could download the font, so it doesn't have to live in the repo.
2. Doesn't google even give you APIs to use a font w/o having to download it (assuming you have a network connection)? Could be an option too?

[whitequark]

All of what you describe is strictly worse than the current behavior. In particular, not requiring any network connection to function is a feature, as is not depending on third-party infrastructure.

[jwesthues]

@virtualritz One version, without network dependencies.

@whitequark I agree, though to say "entities would be smoothly scaled" isn't a great expression of what's needed. Basically, I think you'd want to double the scale factor in the gl matrices (so that all constraints, etc. with lengths hard-coded in pixels get drawn twice as big), and double all line widths expressed in pixels.

[whitequark]

@jwesthues The thing is that there are devices with DPI that call for intermediate scale factors. E.g. the laptop I'm typing this at has DPI of 165 (a full-HD 13" screen). In a browser this calls for a 150% zoom to be usable. In fact this is how I've configured SolveSpace here as well, to the extent that it permits me to.

As the result, both major non-Apple vendors of scalable UIs (which is Microsoft and whoever is maintaining Qt these days) have adopted the algorithm that I describe: assets that only look good when aligned to pixel grid come in discrete increments, the rest is scaled smoothly. Apple, of course, avoids this by shipping hardware in only two DPI choices, corresponding to 1x and 2x.

[jwesthues]

@whitequark Agreed. I was referring above to the specific implementation details to scale the graphics window, and didn't mean to imply that you had to snap the "vector scale factor" to 1 or 2; though if you don't, then you'll also have to adjust for the change in relative font size to make the constraints look right.

[whitequark]

though if you don't, then you'll also have to adjust for the change in relative font size to make the constraints look right.

Yeah. Fortunately the vector font is already fully scalable and e.g. constraint label offsets were rewritten in terms of the font size, so that's a simple matter of adding a factor.

[jwesthues]

Yeah. Fortunately the vector font is already fully scalable and e.g. constraint label offsets were rewritten in terms of the font size, so that's a simple matter of adding a factor.

Wait, isn't what I wrote above wrong? Since the only font used in the graphics window is the vector font, you should be able to scale that entire UI together continuously just by multiplying a scale onto the gl matrices, and lying to the zoom-to-fit and stuff about the window dimensions in physical pixels. That looks pretty easy.

[whitequark]

Since the only font used in the graphics window is the vector font

There are the icons, the bitmap font used in tooltips as well as the regeneration-in-progress message (removed for now, since the implementation doesn't work with offscreen rendering used on non-Windows platforms).

should be able to scale that entire UI together continuously just by multiplying a scale onto the gl matrices

To get a crisp rendering at low DPIs, the vector font uses a simple form of hinting (at character boundaries only), and many entities are also aligned to the pixel grid, so it's not quite as simple as that. But it doesn't require any radical changes either, just a matter of adding a conversion factor in a few places, I think.

[virtualritz]

I don't want anything scaled. The sizes of fonts, dimensions and icons in SolveSpace are perfectly fine on my Retina MacBook. They are just not crisply rendered. And no, the scale factor is not 2. There are different scale factors, depending on what you choose in the Display Preferences of OS X.

[jwesthues]

There are the icons, the bitmap font used in tooltips as well as the regeneration-in-progress message (removed for now, since the implementation doesn't work with offscreen rendering used on non-Windows platforms).

But those are basically just overlays. I don't think anything bad happens if those render at slightly different scale from the rest of the graphics window content.

To get a crisp rendering at low DPIs, the vector font uses a simple form of hinting (at character boundaries only), and many entities are also aligned to the pixel grid, so it's not quite as simple as that. But it doesn't require any radical changes either, just a matter of adding a conversion factor in a few places, I think.

But that hinting doesn't require you to coarsely quantize the vector font size, does it? So it's only the code that renders the font that needs to know the true physical resolution, not e.g. code that just needs to know the bounding box of the text.

[whitequark]

@virtualritz That's because SolveSpace already scales the UI on Retina displays. However, it does that by simply taking the offscreen rendering buffer and stretching it 2x, which is what causes the lack of crispness.

[whitequark]

I don't think anything bad happens if those render at slightly different scale from the rest of the graphics window content.

Sure, it's just a distinction that has to be made during rendering.

So it's only the code that renders the font that needs to know the true physical resolution, not e.g. code that just needs to know the bounding box of the text.

The difference in horizontal width introduced by hinting can be considerable. E.g. (approximate numbers) in a 100 Latin character string it can be maybe 3 or 5 a characters. This actually has interesting effects because looking at text at any angle except truly perpendicular causes it to 'jump' as hinting gets turned off; I originally thought this would make such an implementation unviable but it is almost completely unnoticeable.

[valpackett]

The problem is that Unifont, which we use, is available in 16x16 and that's it. I can scale it 2x I guess.

the all-in-one Noto package is ~89MB archived, as opposed to the current Unifont situation, which is 700KB archived.

uh. Just looked up unifont. If it's this one, the first thing here is a 12 MB truetype font.

(also why not use system fonts and/or let the user choose any font)

Do you have any idea how to test this with Windows in a VM?

I guess you could just set the display scale above 100%? (I have 150% on my 4K monitor)

[whitequark]

uh. Just looked up unifont. If it's this one, the first thing here is a 12 MB truetype font.

It's this one, but we are using the .hex.gz version, which is almost as compact as an actual bitmap. TrueType fonts, as you have noticed, are pretty bad for representing bitmaps.

[whitequark]

@virtualritz Any update on the assets? Meanwhile, I've added preliminary Hi-DPI support to the GTK port as well.

Maybe it would be usefull make some simple "my-own-theme.cfg" template, that would be stored in config folder, that should define how represent UI (icon set, positions of UI elements in main window, etc).

And every user can make own theme.

P.S.: it could be as "load custom theme file" option in "Property Browser"

[whitequark]

No, this would be a complete waste of time.

[Evil-Spirit]

@virtualritz , @whitequark,
We can render unifont in bigger size from .ttf. There is no problem to build distance-map for glyphs and perform alpha-clipping to get perfecly-resizable font in just 16x16 pixels or may be a little bit bigger like 32x32 for precision.

[Evil-Spirit]

@virtualritz, @whitequark
http://wiki.polycount.com/wiki/Transparency_map

[whitequark]

@Evil-Spirit But Unifont only has 16x16 glyphs...

[Evil-Spirit]

@whitequark, It will be raster font with vector quality.

[Evil-Spirit]

[whitequark]

This doesn't actually work for fonts that have been specifically designed to be displayed with pixels

[whitequark]

Haha wow SolveSpace is currently VERY broken on Linux HiDPI systems. Since one is now my main laptop... guess I'll have to address this.

[NikiSchlifke]

Hey, is there anybody working on that right now. I use solvespace on a 276dpi laptop and it's really barely usable.
Regarding aligning svg images on a pixel grid and such, yeah that's nice but actually if you are using a HiDPI display you likely on't care. Because at above around 200dpi you can't even see the difference between naive grayscale anti-aliasing, sub-pixel anti-aliasing, font hinting or no font hinting.

So, can anybody point me on how to implement use svg icons and larger fonts on my own fork, in case anybody is into it I would then be submitting a pull request for the main fork.
Is there svg loading and rendering implemented in any libraries that are already there?

[whitequark]

Just use the master branch, that already has HiDPI support.

[NikiSchlifke]

Just compiling and running it won't result in any changes for me. Perhaps I'm blind I can't see any option in the ui or code that is supposed to do the scaling for that matter.
Can you point me towards the code that is supposed to do the scaling?
All I can find is

solvespace/src/view.cpp

Lines 12 to 19 in 33b6e51

	Printf(true, "%Bd %Ftoverall scale factor%E");
	Printf(false, "%Ba %# px/%s %Fl%Ll%f[edit]%E",
	SS.GW.scale * SS.MmPerUnit(),
	SS.UnitName(),
	&ScreenChangeViewScale);
	Printf(false, "%Bd %Fl%Ll%fset to full scale%E",
	&ScreenChangeViewToFullScale);
	Printf(false, "");

which seems to be regarding the scale of the drawing on the screen, not scaling icons, fonts, etc...

I'm running Ubuntu 17.04 everything stock btw.

[whitequark]

HiDPI support on GTK was added in commit 96476ca. This doesn't actually bring you larger icons or larger text in the browser. Although I still find it quite usable, a quick and dirty way to increase icon and text size would be to scale the viewport 2x when creating UiCanvas.

[valpackett]

it's really smol!! but that's better than blurry :D

[valpackett]

@DougBeney is it just me or does it look kinda blurry? Anyway, while gnome-shell is capable of running Xwayland apps without blur, that's not true for most other compositors.

[NikiSchlifke]

@myfreeweb That is to be expected since these kind of hacks can't change the actual rendering code is still the same. That is still a great help, for usability, if you need it.

There also seems to be some confusion regarding what HiDPi on the desktop actually means, so far only apple has done it right. With a 200+ dpi screen you aren't concerned about "blurriness" when scaling pixel graphics (like the solvespace icons & fonts). Normal desktop gui toolkits are designed for the "96dpi" display "standard" (actual size may differ) HiDPI screens for double of that. Everything that is not drawn as vector graphic should be scaled by 200% by "default" on these screens.

[DougBeney]

Yup. It is a bit blurry.

Another thing you could try is running KDE with Wayland (Not xorg). Just learned about it today, but keep in mind KDE w/ Wayland is not perfectly stable.

The benefits are that there is no lag like there is with the method I described previously. Also, I'm pretty sure there isn't any blur. Maybe a bit with the icons, but probably not anywhere else.

[DougBeney]

Confirmed! Nice work. Luckily, the icons don't look that bad so it's not a major problem.

Icon scaling will be added once someone contributes hi-res icons

I could try create hires icons. Can you give details, what size it should be?

[virtualritz]

The icons should be created as vector graphics with pixel-grid snapped lines (pre-hinted). I started doing this last year but couldn't donate more time to this.
I may have more time soon but I'm happy to hand out what I did to someone else.

@virtualritz, if so, please, attach your icons files (if you could)

[konsultaner]

@whitequark I'm on win10 with a 4k Display scaled to 200% (its a DELL XPS 15 Laptop). High-DPI does not 100% work. I have Issues with my mouse as well. It has a pointer offset.

[whitequark]

Please open a new issue, and provide all the information in the issue template.

[konsultaner]

@whitequark I opened #373