5 ms·

That's precisely why I stated 20 years. Those programs were written before that and largely haven't changed since. If you wan't anti-aliasing in any of those a

That's precisely why I stated 20 years. Those programs were written before that and largely haven't changed since. If you wan't anti-aliasing in any of those above (gitk/emacs come to mind) you'll be doing client side rendering of fonts and copying pixels.

monochromatic 10y ago
> no X client draws like this nor has for 20 years If something was written a long time ago and hasn't changed in this respect, BUT is still widely used... you can't say that "no X client draws like this nor has for 20 years."
fulafel 10y ago
"Copying pixels" is the dominant mode of operation in other remote GUI protocols like RDP, so it's not the end of the world.
- audidude 10y ago
  Indeed. Especially since TCP-based X would require that you stall operations if you drop a packet so that draw-ordering is preserved.
  - fulafel 10y ago
    If you want to optimize for choppy networks that have too much packet loss for interactive TCP applications , then the current X11 is not a good fit. But that would be a whole different niche.
  - digi_owl 10y ago
    Could have sworn that there exist multiple takes on extensions for that, but none that has been rolled into Xorg proper. This either because lisencing, or because the current devs have GPU stars in their eyes. BTW, it is downright funny how just about every Gnome guy i have encountered online seems to come across a pedantic grump. that would not know a joke if it fell on his head...
    - audidude 10y ago
      Interesting how one person is a common denominator in all those interactions ;)
      - digi_owl 10y ago
        And most of the comment gets ignored for a cheap retort, as expected.
        audidude 10y ago
        you've mentioned something i've not heard about without linking to it or providing a name to help me find it myself. so i'm not sure what you'd like from me.
- bitwize 10y ago
  Actually, RDP is GDI over the wire, which is not too dissimilar from X. RDP has efficiency gains because clients send pixmaps over the wire to be stored on the server, and then send draw calls to display those pixmaps in certain places, composing a display. You can do this with X11 too, but the GTK developers don't want to because using the protocol is hard ;_;
  - deleted 10y ago
    [deleted]
  - audidude 10y ago
    gtk+ certainly does use server-side textures and positioned draws. That is why the documentation is so adamant about using API like create_similar_surface(). Even the pixelcache uses server-side textures when available. This is what Xshm does and why everything modern uses it. You get a server-side texture, but mapped into client address space so you can do direct draws and then XCopyArea() into your final location for double-buffering. But gtk+ isn't really in the position to be able to control everything so precisely all the way down the driver stack to network transparency layers. So unless you connect to our process directly, like the HTML5 broadway backend, there is only so much we can do. The broadway backend does employ various techniques to reduce the amount of content passed using a sort of rolling hash. https://git.gnome.org/browse/gtk+/tree/gdk/broadway/broadway-buffer.c https://git.gnome.org/browse/gtk+/tree/gdk/broadway/broadway... I expect forthcoming app/display network transparency layers in GNOME's Wayland compositor to employ a similar strategy.

monochromatic 10y ago

> no X client draws like this nor has for 20 years If something was written a long time ago and hasn't changed in this respect, BUT is still widely used... you can't say that "no X client draws like this nor has for 20 years."

fulafel 10y ago

"Copying pixels" is the dominant mode of operation in other remote GUI protocols like RDP, so it's not the end of the world.

audidude 10y ago
Indeed. Especially since TCP-based X would require that you stall operations if you drop a packet so that draw-ordering is preserved.
- fulafel 10y ago
  If you want to optimize for choppy networks that have too much packet loss for interactive TCP applications , then the current X11 is not a good fit. But that would be a whole different niche.
- digi_owl 10y ago
  Could have sworn that there exist multiple takes on extensions for that, but none that has been rolled into Xorg proper. This either because lisencing, or because the current devs have GPU stars in their eyes. BTW, it is downright funny how just about every Gnome guy i have encountered online seems to come across a pedantic grump. that would not know a joke if it fell on his head...
  - audidude 10y ago
    Interesting how one person is a common denominator in all those interactions ;)
    - digi_owl 10y ago
      And most of the comment gets ignored for a cheap retort, as expected.
      - audidude 10y ago
        you've mentioned something i've not heard about without linking to it or providing a name to help me find it myself. so i'm not sure what you'd like from me.
bitwize 10y ago
Actually, RDP is GDI over the wire, which is not too dissimilar from X. RDP has efficiency gains because clients send pixmaps over the wire to be stored on the server, and then send draw calls to display those pixmaps in certain places, composing a display. You can do this with X11 too, but the GTK developers don't want to because using the protocol is hard ;_;
- deleted 10y ago
  [deleted]
- audidude 10y ago
  gtk+ certainly does use server-side textures and positioned draws. That is why the documentation is so adamant about using API like create_similar_surface(). Even the pixelcache uses server-side textures when available. This is what Xshm does and why everything modern uses it. You get a server-side texture, but mapped into client address space so you can do direct draws and then XCopyArea() into your final location for double-buffering. But gtk+ isn't really in the position to be able to control everything so precisely all the way down the driver stack to network transparency layers. So unless you connect to our process directly, like the HTML5 broadway backend, there is only so much we can do. The broadway backend does employ various techniques to reduce the amount of content passed using a sort of rolling hash. https://git.gnome.org/browse/gtk+/tree/gdk/broadway/broadway-buffer.c https://git.gnome.org/browse/gtk+/tree/gdk/broadway/broadway... I expect forthcoming app/display network transparency layers in GNOME's Wayland compositor to employ a similar strategy.