Re: [cairo] Color fonts

[Behdad Esfahbod]

On Fri, Jul 28, 2017 at 6:00 PM, Bill Spitzak  wrote:

> I think the stacking order of glyphs can remain undefined for
> cairo_show_glyphs. This seems more like something pango would be in
> charge of.
>

We are talking about order of glyphs drawn in one cairo_show_glyphs(), so I
don't see how this is pango's job.


>
> On Fri, Jul 28, 2017 at 7:38 AM, Behdad Esfahbod 
> wrote:
> > Uli,
> >
> > Can we commit this?  I don't think waiting another few years will result
> in
> > a superior patchset. :)
> >
> > Cheers,
> >
> > behdad
> >
> > On Wed, Jul 19, 2017 at 1:53 AM, Behdad Esfahbod 
> wrote:
> >>
> >> Right.  In the future we would want to make it show glyphs in the input
> >> order, ie. not separate color vs non-color.  That's the order required
> by
> >> CSS for example.  In a show-text-glyphs call with
> >> CAIRO_TEXT_CLUSTER_FLAG_BACKWARD, it might be desirable to show
> >> back-to-front.
> >>
> >> On Tue, Jul 18, 2017 at 1:59 PM, Matthias Clasen
> >>  wrote:
> >>>
> >>> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter 
> wrote:
> 
>  On 07.07.2017 15:23, Matthias Clasen wrote:
>  > On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter 
> wrote:
>  >> On 30.06.2017 17:29, Behdad Esfahbod wrote:
>  >>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" 
>  >>> wrote:
>  >>> On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote:
>   On 28.06.2017 14:23, Behdad Esfahbod wrote:
>  > All of you have asked me about the status of color fonts in
>  > cairo.  There's
>  > some discussion here:
>  
>   what was the solution to make this fit into cairo's drawing
> model?
>   Text
>   / glyphs are used as a mask and a mask does not have colors.
>  
>  >>>
>  >>> There is no solution to that. The assumption in cairo's drawing
>  >>> model
>  >>> about glyphs/fonts has simply been invalidated by reality.
>  >>>
>  >>>
>  >>> Correct.
>  >>
>  >> 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.
> 
>  Hi again,
> 
>  I just came up with another question: How are overlapping glyphs
>  handled?
> 
>  Let's say I have a red glyph and a blue glyph and I draw them in such
> a
>  way that they overlap. Let's say this additionally overlaps with a
>  non-colored glyph in the same position and I use a green source with
> 50%
>  alpha (cairo_set_source_rgba(cr, 0, 1, 0, 0.5)).
> 
>  What's the visible result?
> 
> >>>
> >>> Here is what my implementation does: It renders the color glyphs, in
> >>> order, followed by the non-color glyphs.
> >>>
> >>> In practice, I don't think the case of mixed color and non-color glyphs
> >>> in the same call will be all that common.
> >>> Most apps will explicitly set a color font just for the emoji and they
> >>> won't render regular text with an emoji font,
> >>> with the result that runs of color glyphs and non-color glyphs will
> >>> typically be in separate calls.
> >>
> >>
> >>
> >>
> >> --
> >> behdad
> >> http://behdad.org/
> >
> >
> >
> >
> > --
> > behdad
> > http://behdad.org/
> >
> > --
> > cairo mailing list
> > ca...@cairographics.org
> > https://lists.cairographics.org/mailman/listinfo/cairo
>



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

Re: [cairo] Color fonts

[Behdad Esfahbod]

Uli,

Can we commit this?  I don't think waiting another few years will result in
a superior patchset. :)

Cheers,

behdad

On Wed, Jul 19, 2017 at 1:53 AM, Behdad Esfahbod  wrote:

> Right.  In the future we would want to make it show glyphs in the input
> order, ie. not separate color vs non-color.  That's the order required by
> CSS for example.  In a show-text-glyphs call with 
> CAIRO_TEXT_CLUSTER_FLAG_BACKWARD,
> it might be desirable to show back-to-front.
>
> On Tue, Jul 18, 2017 at 1:59 PM, Matthias Clasen <
> matthias.cla...@gmail.com> wrote:
>
>> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter  wrote:
>>
>>> On 07.07.2017 15:23, Matthias Clasen wrote:
>>> > On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter  wrote:
>>> >> On 30.06.2017 17:29, Behdad Esfahbod wrote:
>>> >>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" 
>>> wrote:
>>> >>> On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote:
>>>  On 28.06.2017 14:23, Behdad Esfahbod wrote:
>>> > All of you have asked me about the status of color fonts in
>>> > cairo.  There's
>>> > some discussion here:
>>> 
>>>  what was the solution to make this fit into cairo's drawing model?
>>>  Text
>>>  / glyphs are used as a mask and a mask does not have colors.
>>> 
>>> >>>
>>> >>> There is no solution to that. The assumption in cairo's drawing model
>>> >>> about glyphs/fonts has simply been invalidated by reality.
>>> >>>
>>> >>>
>>> >>> Correct.
>>> >>
>>> >> 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.
>>>
>>> Hi again,
>>>
>>> I just came up with another question: How are overlapping glyphs handled?
>>>
>>> Let's say I have a red glyph and a blue glyph and I draw them in such a
>>> way that they overlap. Let's say this additionally overlaps with a
>>> non-colored glyph in the same position and I use a green source with 50%
>>> alpha (cairo_set_source_rgba(cr, 0, 1, 0, 0.5)).
>>>
>>> What's the visible result?
>>>
>>>
>> Here is what my implementation does: It renders the color glyphs, in
>> order, followed by the non-color glyphs.
>>
>> In practice, I don't think the case of mixed color and non-color glyphs
>> in the same call will be all that common.
>> Most apps will explicitly set a color font just for the emoji and they
>> won't render regular text with an emoji font,
>> with the result that runs of color glyphs and non-color glyphs will
>> typically be in separate calls.
>>
>
>
>
> --
> behdad
> http://behdad.org/
>



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

Re: g_io_channel_win32_poll() Problem on Windows

[LRN]

On 7/28/2017 3:08 PM, Paul Davis wrote:
> 
> 
> On Fri, Jul 28, 2017 at 4:37 AM, LRN wrote:
>> After trying this myself (for unrelated reasons), i found that *only*
>> giochannel GSource does WSAEventSelect() on a socket event (in
>> g_io_win32_prepare()) to bind it to an event handle, which can then be 
>> polled.
>> If you are not using a main loop (and GSource), then this doesn't happen, and
>> the events you feed to g_poll() are completely inert.
> 
> This is true on all platforms. The "responsiveness" of all GSources depends on
> a main loop that
> polls/selects/does-some-platform-equivalent-of-wait-for-something.
>  

That's not what i meant. On Windows g_poll() is just a glorified
WaitForMultipleObjectsEx() that waits on an array of handles.
The polling of sockets is done in a very circuitous way - and event is bound to
a socket with WSAEventSelect(), then that event is polled, then, once the event
is signaled, the code in W32-socket-based GSource calls WSAEnumNetworkEvents()
to get the socket-level events triggered the signaling.

For blocking I/O (W32 nameless pipes) same thing applies - the events that
g_poll() waits upon are, in fact, special events attached to a separate thread
that does the actual I/O.

g_poll() itself does almost nothing. The revents that it fills in the GPollFD
structs are just copies of the events field (the copying is done when the
corresponding event is signaled).

So, the main takeaway here is that you should either do what GSource+gmainloop
do (source prepare, then g_poll, then source check), or just use 
GSource+gmainloop.

-- 
O< ascii ribbon - stop html email! - http://arc.pasp.de/


0x6759BA74.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_io_channel_win32_poll() Problem on Windows

[Paul Davis]

On Fri, Jul 28, 2017 at 4:37 AM, LRN  wrote:

>
>
> After trying this myself (for unrelated reasons), i found that *only*
> giochannel GSource does WSAEventSelect() on a socket event (in
> g_io_win32_prepare()) to bind it to an event handle, which can then be
> polled.
> If you are not using a main loop (and GSource), then this doesn't happen,
> and
> the events you feed to g_poll() are completely inert.
>

This is true on all platforms. The "responsiveness" of all GSources depends
on a main loop that
polls/selects/does-some-platform-equivalent-of-wait-for-something.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_io_channel_win32_poll() Problem on Windows

[LRN]

On 7/27/2017 2:56 PM, LRN wrote:
> On 7/27/2017 2:06 PM, Faik wrote:
> 
>> As you might guess, in  arv_gv_discover_socket_list_new() function,  GPollFDs
>> are created and in _discover() function, a broadcast message is sent and then
>>  polled for reply. but no luck, still in _discover(), it time outs.  By the
>> way, in Linux, the same application works smootly.
>> I also checked the discovery packet was actually emitted, and I saw a camera
>> discovery ack packet coming to my network adapter via WireShark.
> Portable I/O is tricky. If i were in your place, i would write the simplest
> possible code that does this thing (creates a socket, sends a broadcast
> message, then waits for a reply) using W32 socket API only. Once *that* works,
> figure out what glib is doing differently. Since you're providing the socket
> object to glib, at least socket creation part is already in your hands. IIRC,
> glib calls WSACreateEvent() to create an event handle, then binds it to the
> socket using WSAEventSelect(), then just waits on the event handle using
> conventional WaitForMultipleObjects...() (in your case WaitForSingleObject
> would probably be enough). Once it indicates that the event is set, glib calls
> WSAEnumNetworkEvents () to see which socket events happened.
> 

After trying this myself (for unrelated reasons), i found that *only*
giochannel GSource does WSAEventSelect() on a socket event (in
g_io_win32_prepare()) to bind it to an event handle, which can then be polled.
If you are not using a main loop (and GSource), then this doesn't happen, and
the events you feed to g_poll() are completely inert.

Thus, apart from creating sockets yourself, you should also call call
WSAEventSelect(). It might be possible to offload this to glib by pretending to
be a main loop, but driving stuff manually, but i haven't checked that yet.

-- 
O< ascii ribbon - stop html email! - http://arc.pasp.de/


0x6759BA74.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list