Render and dpi enhancements #236
Conversation
Some scripts unconditionally remove complete assets subdir. Could be global behaviour.
- Light-dark suffixes - Assets gtk subdir name
Get rid of inkscape's glib warnings flood.
Resembling make jobs, but without dedicated jobs server. Thus, limited to only one script scope. Jobs are performed in packs rather than continuous stream, waiting for all jobs in current pack before going to next or exiting script.
Also restore original default scales
Adjusts themerc along with assets. Current xfwm4 can only be adapted for HiDPI by creating special theme.
- Space-separated integers list - Sort and deduplicate - Drop scale 1 from list, since it's essential (empty SCALE_FACTORS should be valid).
- Include assets for all configured SCALE_FACTORS into gresource. - Preprocess gtk scss, converting default HiDPI image url calls to arguments list, according to configured SCALE_FACTORS. - However, do nothing for default SCALE_FACTORS="2", which is default. CSS must be renenerated with same SCALE_FACTORS to keep theme consistent.
Cloned metacity-1 theme with some disabled resources.
Current version is tuned for specific scale. Also nothing forces internal line aliasing. XFWM4 seems to be able to get shape from png alpha channel, but if necessary - imagemagick could be used for correct preprocessing.
Configuration is maintained by render-assets.sh, stored in file - no need to specify all parameters each time. parse-scss.sh converts it to config.scss for css regeneration. -gtk-scaled() hidpi args lists are generated in more elegant way, using sassc builtin capabilities instead of rather hackish external filtering.
|
Besides broken code in thumbnails regen due to typo - just could not stop from to try more elegant solution with parametrized multi-dpi assets lists in While in process - reworked configuration system, so no more need to repeat same env variables for each stage (render -> parse-scss -> install) each time, since variables are stored in files and reused. First (I suppose) stage, render-assets.sh, writes passed env variables to config files. Other stages (parse-scss, install) just reuse it. For now I limited including config.sh only to root scripts, leaving subtask scripts to use derived env. |
Incomplete commit 3c9019d (lost changes)
Sass documentation tells in context of loop at-rules, that trailing commas are allowed, but something seems to be wrong.
|
Looks like, all additional scales, from 2 to max, must be listed - either P.S. Once more ensured, that themes build and work as expected (gtk2, gtk3, xfwm4, unity via xfce4-windowck-plugin). |
-gtk-scaled() seems expecting argument positions to be same as scales. Attempt to pass scale 3 right after 1st arg leads to unexpected result.
I needed support for other DPI while testing this desktop configuration (well, that's picom shader, whose description includes the config).
However I can mention, that 4k 15in display should be almost exactly 3x 96dpi. And considering, that various displays could need to be used at different time - multiple DPI support should be justified.
As for my case - my display is 1366x768, but with above configuration - virtual resolution is probably most honest 4k.
There are number of enhancements, accompanying bare DPI support, some may need discussion.
Total
Render subsystem
Scale factors
Makes to generate assets for each and patches related scss to include all in
-gtk-scale()args. NOTE: must be accompanied with followingparse-scss.shto be consistent. List is parsed and reinterpreted. Duplicates of scale 1 are droped. For empty list - single value 2 is used (scale 1 is essential, thus not in this list).Other components either not tested or can't use upscaled assets properly (e.g.
Special note: It seems, window manager themes used 90dpi instead of 96, which could be if it was old inkscape files (it's told in inkscape docs to use such dpi, requiring a conversion). I simply assumed inkscape is able to recognize and properly handle old formats, so replaced with 96 (need to know if 90dpi must be used). At least it could not be for small buttons, which have special resource name in svg files.
Also about build jobs. Inkscape is not as good as gcc at making full 100% load if number jobs is same as for cores, but using double jobs number makes load better.