Re: Non-integral scaling factors: best practices?

[Brion Vibber]

On Thu, Apr 27, 2017 at 3:58 PM, Emmanuele Bassi  wrote:

> To be fair, 1080p displays with higher-than-192 DPI densities are a
> temporary oddity, and are being phased out to the lower end of the
> spectrum by HiDPI displays on laptops, and by 4K and 5K displays on
> desktops. The cost is still high, but we (Endless) have already
> started seeing HiDPI panels in laptops that are starting to target
> emerging markets


Good news! :)


> In general, desktop environments will keep a scaling
> factor of 1x on 1080p displays, regardless of DPI density. Changing
> the font-scaling factor to increase the font size is a valid solution;
> for instance, GNOME could keep the window scaling factor to 1x and
> make fonts 1.25x bigger if it detects a 1080p display.
>

*nod* I've done this manually on Linux laptops in the past. At 1.25x it's
not too bad, but at 1.5x many widgets and icons are visibly smaller than
expected because they don't get scaled along with the font size. This is
usually ok, though icons can be hard to click and occasionally text in
small widgets overflows.


> > I don't know if it's either feasible
> > or desirable to just rip out the integers and replace with floats...
>
> No, it's not desirable.
>
> Windowing system surfaces cannot be "half pixel" in size; graphical
> assets and fonts positioned or sized with sub-pixel precision will
> appear blurry and won't look right.
>

Gotcha. :)

>
> The appropriate way to do fractional scaled rendering at 1.5x is to
> render at 3x scale, and have the compositor downscale by a factor of
> 2x; this is also what macOS does. Of course, this needs cooperation
> from the windowing system, as the scaling must also affect the input.
> This is why, on Linux, we're going to rely on Wayland compositors to
> do the right thing (X11, sadly, cannot do input transformations).
>

Great; that'll be awesome on Linux once supported throughout the stack
consistently.

My main remaining concern would be cross-platform GTK+ apps on Windows.
Windows uses compositor & input scaling to display non-HiDPI-aware apps
scaled up as necessary, but I'm not sure offhand if one can override it to
do things like downscaling a 3x rendering to 1.5x display. Sticking with
integral window scaling plus non-integral font scaling for that would keep
things simpler.

I haven't seen a lot of GTK+3 apps with Windows ports yet, but I often use
both GIMP and Inkscape (GTK+2) on various OSs and I believe both have GTK+3
migrations coming along.


> > Alternately, would it make sense to recommend best practices for
> > applications to make display sizes of non-text elements scale along with
> the
> > font scaling factor?
>
> Applications shipping assets should ensure to have *at least* 2x
> scaled images, and should be coded defensively in case the scaling
> factor is >2x; they should also always ensure that everything is pixel
> grid aligned when positioning and sizing assets manually, instead of
> using the toolkit layout managers.
>

Should application developers try to scale widgets according to the font
scale, such as using 'em' or 'rem' units in CSS? Or should we just accept
that a lot of widgets (especially those with bitmap icons) will appear
small in the 1.5x font-scale scenario for now?

Thanks!

-- brion
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Non-integral scaling factors: best practices?

[Brion Vibber]

GTK+3 added native support for user interface scaling to support HiDPI
displays with consistently sized resources and widgets, with the limitation
that the scaling factor is an integer (1x, 2x, 3x...)

This seemed a good bet when the earliest HiDPI iOS, MacOS and ChromeOS
machines all came out at 2x, and holds for many high-end PCs... However, PC
laptops with 1920x1080 screens that need a 1.5x or so scaling factor are
now quite common, and a lot of people have CC'd themselves on this old bug
asking about it: https://bugzilla.gnome.org/show_bug.cgi?id=720502

This also means non-integral scaling factors are common on Windows, which
may affect cross-platform apps using a GTK+ front-end.

Is there anything that could be done in the GTK+ 4 dev cycle to better
support non-integral scaling factors? I don't know if it's either feasible
or desirable to just rip out the integers and replace with floats...


Alternately, would it make sense to recommend best practices for
applications to make display sizes of non-text elements scale along with
the font scaling factor?

For instance, there might be a recommendation that a 1x window scaling
factor with a 1.5x font scaling factor should scale icons, buttons,
toolbars etc in their units by 1.5x. There may also need to be a consistent
way to load image resources at intermediate scales (or a recommendation to
load the 2x resources and scale down).

This would result in apps at (window 1x, font 1.5x) would look about the
same as they would have if (window 1.5x, font 1x) were supported... But
might be a change for people who specifically wanted larger text but not
larger icons and other widgets. Would that be likely to be problematic?


Thanks for any feedback and ideas -- and thanks everybody for all your work
on making GTK+ an awesome toolkit for Linux (and cross-platform) apps!

-- brion
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.x and broadway ( and other remote options )

[Brion Vibber]

On Tue, Dec 6, 2016 at 8:00 PM, Fan, Chun-wei via gtk-devel-list <
gtk-devel-list@gnome.org> wrote:

> Specifically what this means is that there isn’t OpenGL support in it (we
> need OS/platform-level support for OpenGL for creating and switching
> (making current) OpenGL contexts), which likely needs to be done with
> WebGL, which most probably needs to be done in the .js file in the broadway
> subdir in gdk/.  GTK+-4.x is going to switch to GL drawing, at least for
> the majority of the various components, which makes OpenGL support a
> requirement.
>
>
>
> AFAIK, the backends that have the needed support are x11, Wayland, mir and
> Windows.
>
>
>
> If you know how to do initialize OpenGL in WebGL (ie Javascript), please
> let the people know here, as this is what I think is mainly what needed for
> Broadway to stay.
>

WebGL is roughly equivalent to a JavaScript API for OpenGL ES 2 (not full
OpenGL). Since it runs on the remote browser side, not in-process with the
app, I believe you'd need support in the local (app-side) OpenGL driver to
get the GL calls made in the app to actually talk to the web page.


I think there are two main possibilities:

1) Remote the OpenGL commands over the network to JS running in the
Broadway renderer's HTML page, assuming that quasi-OpenGL ES 2 is enough to
do GTK+'s rendering (or that any necessary bits can be emulated in WebGL).

This may require replacing the OpenGL library provider with a custom one,
or digging around in Mesa3d to provide a suitable driver.


2) Use local headless GL rendering with default software or native GPU
rendering, with some way to push on-screen bitmap updates as efficiently as
possible over the network.

For native GPU, may require suitable permissions to access the kernel
drivers.


I'm not sure how easy either is, though both should be possible.

-- brion
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GdkGLContext for Mac OS X Quartz backend patches

[Brion Vibber]

I've already showed these to Emmanuel last week on IRC, but want to make
sure they're ready to merge soonish so they don't bitrot...

Unfortunately my gtk+ patch has already bitrotted since last weekend; the
'update' method has been removed on master which I was relying on to call
the NSOpenGLContext's update method after a window resize; this leaves
GL-rendered windows broken after resizing.

What would be a recommended place to insert that update call instead?


I also have not yet figured out why the gtk3-demo 'golden triangle' demo
updates the screen properly on update, but the gdkgears demo does not. Help
with that would be welcome. :)


Patches to gtk+ on bug:
https://bugzilla.gnome.org/show_bug.cgi?id=740199

Patch to cairo on bug:
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=69796

The cairo patch is provisional and may need further work; basic problem is
that a quartz surface created for a window takes its device scale into
account on the Quartz (CGContext) side but the cairo side doesn't know
about it and treats it like a 1x-scaled surface. This was leading many
things to 'work' in GTK+ due to the gdk-quartz cairo stuff not actually
applying device scale on surfaces either... but offscreen surfaces used for
scrolling and GL rendering ended up really treated as 1x leading to
low-resolution widgets being displayed in some places. In my gtk+ patches I
fix gdk-quartz to set the window's device scale resolution on the cairo
surface, which requires this cairo fix (or one very like it). Possibly the
cairo fix should set the cairo-level device scaling on the surface as well,
which I think would be redundant in the GTK+ case but might be a wise
default.


Thanks!

-- brion
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: MDI (not winMDI) frameworks ... again

[Brion Vibber]

Tim wrote:
Regarding MDI, I still see many apps that are being developed that don't 
have MDI support and they really need it. A good example is BBEdit on 
Mac. I don't use this app because it's just too hard to manage the 
multiple sources I have open at one time to do my coding.
You might try out the BBEdit 8.0 demo just to take a look at how they're 
now doing it: you can combine multiple open documents into one window, 
with a drawer containing the list of files in that window to pick from.

Compared to tabs in gedit et al I find it pretty awkward for two or 
three files (the drawer's so big!) but pretty nice for a hundred files, 
where I can actually see thirty or so filenames at a time even on my 
little PowerBook screen... Tabs along the top in gedit become impossible 
to navigate after just a handful of open files, and document menus don't 
have scroll bars.

-- brion vibber (brion @ pobox.com)


signature.asc
Description: OpenPGP digital signature
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: MDI (not winMDI) frameworks ... again

[Brion Vibber]

Tim wrote:
In the meantime, developers are left hanging with putting out apps that 
have just way too many windows. I've used Gimp on my OSX box and it 
totally sucks having to first clicking the window to get focus before 
being able to click the item. If the app ran on a MDI framework, this 
would not be necessary.
Incidentally, you can make Apple's quartzwm behave in a more sensible 
manner. At a terminal:

  defaults write com.apple.x11 wm_click_through -bool true
I've found this makes Gimp actually usable... :P
-- brion vibber (brion @ pobox.com)


signature.asc
Description: OpenPGP digital signature
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list