Re: Multi DPI user interface

On Tue, Jul 19, 2016 at 01:09:15PM -0700, Christian Hergert wrote:
On 07/19/2016 12:21 PM, Ray Strode wrote:
On Tue, Jul 19, 2016 at 11:04 AM Jonas Ådahl <jadahl gmail com> wrote:
2) Represent each monitor separately, generating one file for each
This makes the most sense to me.  Or even only do the active monitor.

This is what I've been leaning towards as well. It does require some
design work (gnome-screenshot needs to be redesigned) and probably some
D-Bus API changes.

Of course for screen recording (versus screenshoting), only doing the
active monitor could be weird, if the user moves their mouse from one
monitor to the other mid recording.

Eventually, I think we should use a screen cast tool (like this[0] one),
where you select the monitor(s), and where mutter/gnome-shell would only
hand over the framebuffer/pixels/... to an external process for
processing. In the mean time, if we want to avoid the
large-framebuffer-with-void-areas, we'd either need to somehow select a
output, or have one video encoder per monitor which I suspect might be a
bit heavy.

I don't like how, today, a small monitor next to a big monitor leads
to screenshots with large void areas.


People I trust have said very good things about CGDisplayStream[1].

If we were to focus on an API like this then we can defer the policy of
how to handle the situation appropriately to the target application.

Determining which applications have authorization to access this API is
a separate issue.

I think as far as API's go, we should use D-Bus API that provides a
screen record session where the actual video frames are passed using
pinos. That API shoulda definitely be per monitor to minimize any
processing done in the compositor process. Encoding etc would be done in
a separate process.




-- Christian

desktop-devel-list mailing list
desktop-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]