Re: color fonts and CAIRO_OPERATOR_SOURCE

[Behdad Esfahbod]

It was actually not that complicated:
https://bugs.freedesktop.org/show_bug.cgi?id=102661

On Mon, Sep 11, 2017 at 1:44 AM, Uli Schlachter  wrote:

> Hi everyone,
>
> yesterday I was asked to comment here:
>
> https://github.com/i3/i3/pull/2925
>
> The issue seems to be: With operator SOURCE, drawing a color glyph
> clears the entire surface. So, while "normal" glyphs are supposed to be
> a mask that is then filled, color glyphs seem to be handled as an
> unbounded source. This doesn't make a difference for OVER, but for lots
> of other operators (at least SOURCE) it obviously matters.
>
> I didn't investigate this at all. I did not even try to reproduce.
> Hence, this ping. Could one of you please look at this, confirm this
> really happens, and say what should be done about this? Thanks.
>
> And yes, in the thread on color fonts, Matthias Clasen answered one of
> my questions with:
>
> >> Okay... so what is the new model? What happens when I draw a color glyph
> >> with operator XOR and a red source?
> >
> >
> > The red source is ignored for color glyphs because they are used as the
> > source.
>
> So apparently this behaviour is by design, meaning that glyphs can only
> really be used with operator OVER any more (well, and some others). So
> let me ask this another why: Is this really a good behaviour?
>
> Oh and one more thing: Who updates cairo's docs and all the explanations
> on the web page? ("glyphs work like this, except when they do not").
>
> Cheers,
> Uli
>
> P.S.: The list of recipents is copied from the recent thread on color
> fonts. I have no overview of how people ended up in this list. Sorry if
> $YOU are the wrong recipent.
> P.P.S: Yes, I also included Gtk-devel-list. I vaguely remember someone
> saying that this stuff is relevant there. Dear moderator, sorry for the
> work that this causes you.
> --
> 99 little bugs in the code
> 99 little bugs in the code
> Take one down, patch it around
> 117 little bugs in the code
>   -- @irqed
>



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

Re: GApplication process uniqueness, saving config files and multi-seat support

[Sébastien Wilmet]

On Mon, Sep 11, 2017 at 02:25:43PM +0200, Bastien Nocera wrote:
> As a general rule, we don't support being logged in to the same account
> on 2 different seats, whether they share the same physical machine, or
> just the backing storage.
> 
> On physical machines, this is enforced by gdm, and a shared user D-Bus, 
> which mimicks the old session bus.
> 
> In short, not something to worry about.

OK, thanks for the info.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GApplication process uniqueness, saving config files and multi-seat support

[Bastien Nocera]

On Sun, 2017-09-10 at 13:27 +0200, Sébastien Wilmet wrote:
> Hi,
> 
> With GApplication process uniqueness, an application has a unique
> process per user *session*. But with multi-seat support, it is
> possible
> AFAIK to open several graphical sessions for the same user.
> 
> Some GTK+ apps save some config/data in e.g. XML files for stuff that
> don't fit well in GSettings, saved typically in ~/.config/ or
> ~/.local/share/.
> 
> So it means that if the same app is opened for the same user in two
> different sessions, several processes can write to the same XML file,
> so
> there can be races, and ideally the app needs to synchronize its
> state
> wrt the XML file.
> 
> I think a lot of applications don't cope well with that situation.
> 
> If I'm not mistaken, the same problem can happen with NFS-mounted
> home
> directories.
> 
> So I think in those setups, there are a lot of potential bugs in GTK+
> applications, because developers (prefer to) think that process
> uniqueness is per *user*.
> 
> Some questions:
> - Does the problem really exists?
> - Is there a recommended way to handle that situation?
> - Is there a way to test easily the situation without multi-seat
>   hardware? E.g. with VMs. Something automated, to also being able to
>   write unit/integration tests, or something that e.g. GNOME
> developers
>   could launch easily.
> - Or nobody cares about that problem?

As a general rule, we don't support being logged in to the same account
on 2 different seats, whether they share the same physical machine, or
just the backing storage.

On physical machines, this is enforced by gdm, and a shared user D-Bus, 
which mimicks the old session bus.

In short, not something to worry about.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [cairo] color fonts and CAIRO_OPERATOR_SOURCE

[Matthias Clasen]

On Mon, Sep 11, 2017 at 4:44 AM, Uli Schlachter  wrote:

>
>
> So apparently this behaviour is by design, meaning that glyphs can only
> really be used with operator OVER any more (well, and some others). So
> let me ask this another why: Is this really a good behaviour?
>

I think you are jumping to conclusions here. The only glyphs for which this
is a problem
with the current code are color glyphs. Most glyphs are still fine with
other operators. One
answer I gave on irc is: if you want to do fancy stuff with text, you
better control which
fonts are involved, so use a custom context (which can avoid loading color
glyphs for the
emoji family). But that is not a great answer. Some ideas for a better one:

- Add an api to find out if a fond has color glpyhs
- Add an api to control loading of color glyphs
- Clip when painting color glyphs to not affect the target outside the
extent of the glyph


> Oh and one more thing: Who updates cairo's docs and all the explanations
> on the web page? ("glyphs work like this, except when they do not").
>

 I can take a look at docs. No idea about the web page.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list