From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id C28DD28CBB for ; Tue, 6 Aug 2024 18:40:32 +0200 (CEST) Received: from mail-oa1-f46.google.com ([209.85.160.46]) by 9front; Tue Aug 6 12:37:14 -0400 2024 Received: by mail-oa1-f46.google.com with SMTP id 586e51a60fabf-26110765976so191999fac.1 for <9front@9front.org>; Tue, 06 Aug 2024 09:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722962233; x=1723567033; darn=9front.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=43G02eGsC/romfsXAtU9hN3l7aE2jL2Nbj8Y3Uq4rYI=; b=K0k8zWvf4jKacTARqgfRqpLY1HhmB5bQQqcWlz39uVQsLRPJ72QpdqgiIdNfKxHoLV k9c4fK/HGzmJ3JLTyUe5tZRuZKtDCE9vv3FPlEBcqTikTs2LFC9SCRQkeZr7XK/QrMw8 LGv6bCta1tUZKaGA7klvyq794RRIB0crb5z3wzdIyct2xWSKLiRw5//X6DC/RgvTj0j3 qRt01sy1/68LboEKCLCXrgk6Hyl7iaddx/8abW92hV1PWJGYvc8LjJA82wYw9xK6mFPq 0JQQqex0NyPfx5e5tph3shuQiJ2ij/Fnkf3Aa/YvUf8ej0KKg4k0SdCub8Gxz8wEnDHY N+RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722962233; x=1723567033; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=43G02eGsC/romfsXAtU9hN3l7aE2jL2Nbj8Y3Uq4rYI=; b=YTSHLHJ0ewBDhrnQmRmP0aQsSAWrRp/h6OG7zcjWUlV7jGSjG7uhfuRbd5Yvl+IPpV OkdeSfVQX+++54KWIrwwnkaXKlnr/d9QzTxbUNnolXMO/x0TWqyhqSa1URhxVMTyCD/f un0aYZ2YM1cdfqvXbW469UQq6X/6cPbrV4vv5AkCHzfmytsBHGyHv1RHdlNn8uC0wyCc QMRQQJ/m8ssUB+sEZOWfiq++08Npc1x4F8QN0kbt7RbvXme0BMDIwz73fTqePjKBynbq z1ZhLn9VZKcJ41JCIZC4D/C2kTCGXdvcXfHuDIhbNtVZifBCBO4hjiCG0n9SpFAl5Yy2 YzLA== X-Gm-Message-State: AOJu0YxuDhtssat94Z0lUc5vfyhYQBEuDBiFPjnQ6lb6Qbae2rt/pAmu ASrxCBw1MQrFTS3Zyaie7eYbIy9NBVr4SHKey8YQqz3geBOghPp7ZNcVzjTHWjb1DbuB8sP3xYF TXOAB3CyaFie0Z73BUMvVTlq5CoWnBXl+D8APFQ== X-Google-Smtp-Source: AGHT+IHKJUK2j1ATYOjymRAvw+O26q8ot+s9TlpL4GJwVgx616rkCJFRkmvjSWEvfH9wPfOpdRLjNxa1cXJ1l+oI9kY= X-Received: by 2002:a05:6870:b619:b0:260:f1c4:2fe3 with SMTP id 586e51a60fabf-26891f05ecdmr8439005fac.10.1722962232698; Tue, 06 Aug 2024 09:37:12 -0700 (PDT) MIME-Version: 1.0 References: <6FB99C7720140A4B3969EA601A4B3588@eigenstate.org> <20240805115126.rm47l4ifx7rrwgtx@black> In-Reply-To: <20240805115126.rm47l4ifx7rrwgtx@black> From: hiro <23hiro@gmail.com> Date: Tue, 6 Aug 2024 18:37:02 +0200 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: out-scaling proxy NoSQL rails Subject: Re: [9front] Thoughts on Wayland? Reply-To: 9front@9front.org Precedence: bulk > needs to be. Plus, AA really benefits everyone, and > https://en.wikipedia.org/wiki/X_Rendering_Extension is only for fonts, not > for arbitrary graphics. (Same problem as on Plan 9. Should we blame Keith > Packard for not going further than just font rendering?) There's no way to > have AA in arbitrary 2D graphics rendered on the X server, AFAIK. What do you need AA for at all? It just makes everything look blurry to me, and even for fonts I often disable this behavior (Though at my low resolution that works only for high quality fonts that have good hinting parameters embedded). A lot of software depends on hand-crafted pixel art in their icons, I see only downsides, let's avoid resampling and AA completely unless we render our own oversampled images from something of much higher or infinite (vector) resolution (for example like with fonts). > So > basically the widget toolkits gave up on supporting efficient networked X11 > ages ago, and not for completely frivolous reasons. If they tried at all! > But if video streaming is the solution, it seems to me an assumption is > being made that the server (where the applications run) has a GPU then: it > would help for rendering the applications (with AA, blending, animations > and all), and it would help for video compression too. Somewhat of a break > from tradition then. I agree that a solution designed specifically with low > bandwidth and low latency in mind ought to be better. But is 9p really for > that? I'm trying to work that way; time will tell... My guess would be it's the other way around, the blit specific multiplexing idea survives in a generalized way as 9p. The precursor to the draw RPCs were meant to be multiplexed together with other concurrent streams from and to the blit terminal, only later 9p generalized this approach to cover not just terminals and their mouse, keyboard and display. Instead, every ressource can be accessed as a file and all file access multiplexed over a single 9p mount. This is nicer than a new custom multiplexing protocol for every service. Back then multiplexing multiple concurrent accesses over a single synchronous bidirectional pipe must have seemed like magic. I fear it still does on the other Unix-descendants. It still seems like magic when I see them reinventing it over and over again in the HTTP2 and Quic fields.