Re: g_io_channel_win32_poll() Problem on Windows
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
Re: g_io_channel_win32_poll() Problem on Windows
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
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: [cairo] Color fonts
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: [cairo] Color fonts
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