From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13832 invoked from network); 28 Jan 2022 15:28:10 -0000 Received: from tb-ob1.topicbox.com (64.147.108.173) by inbox.vuxu.org with ESMTPUTF8; 28 Jan 2022 15:28:10 -0000 Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob1.topicbox.com (Postfix) with ESMTP id 6BD95366C9 for ; Fri, 28 Jan 2022 10:28:08 -0500 (EST) (envelope-from bounce.mMbe750adf3a20ec4a7f7c7b5d.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id 68F5F13FF363; Fri, 28 Jan 2022 10:28:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=to:subject :message-id:references:in-reply-to:date:mime-version :content-type:content-transfer-encoding:from:list-help:list-id :list-post:list-subscribe:reply-to:list-unsubscribe; s=dkim-1; bh=DDJHeuDNse2Qre9+FxS5a/gJDibxly5VGSGbfxOrsGQ=; b=RTwQFxqzQsBV VA9gUNpu6zuT/OuTtO7byco/7ysxO8oSXdBjoBaXglkwnS88ZwYNXOSjgcv38xdA RVBKhGLrri6uS3Z6XSBm22AhBDT9uTNrQgvmWdNs/JyJ92CcKVdgznzePNOR6DU6 pVIVThEbXkgYE7f92LyUunKU+Rbb2qM= To: 9fans <9fans@9fans.net> Subject: Re: [9fans] suggestion : new service targets for plan9 Message-Id: <16433836780.fDb0.34398@composer.9fans.topicbox.com> References: <16433354030.97ACA3.134633@composer.9fans.topicbox.com> <1942de7a-1126-7600-3b36-69ce2effd610@fjrhome.net> <16433724910.4fa96.617630@composer.9fans.topicbox.com> <7Ad_k2SFVPp1bxcNqGCiOKNrQceD7FS-YAAtZs2SMCoPk8DELtakra290--rxDS7haPlflgT5a4a_ePOTjSNHxpqe_FaenTWFnAgp4SEmp0=@protonmail.com> In-Reply-To: <7Ad_k2SFVPp1bxcNqGCiOKNrQceD7FS-YAAtZs2SMCoPk8DELtakra290--rxDS7haPlflgT5a4a_ePOTjSNHxpqe_FaenTWFnAgp4SEmp0=@protonmail.com> Date: Fri, 28 Jan 2022 10:27:58 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=16433836781.FaFfE5.34398 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: df733344-804e-11ec-9890-1b869134e1fa Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UMjUxOGY5ZTRmYzEwZWQwMy1NYmU3NTBhZGYzYTIwZWM0YTdmN2M3?= =?UTF-8?B?YjVkPg==?= From: "ibrahim via 9fans" <9fans@9fans.net> List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:Mbe750adf3a20ec4a7f7c7b5d:1:EqkaQg3TZ8SD0kB5B7vv2fF4W46tn3d2tzdhoOjT5Ew --16433836781.FaFfE5.34398 Date: Fri, 28 Jan 2022 10:27:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, 28 January 2022, at 3:11 PM, Philip Silva wrote: > I didn't deep-dive yet into the internals of it, but isn't it that when c= ombining the images at the end, that transfer of the initial images with lo= ts of data basically happens only once? It seems to me devdraw can be quite= performant on certain use cases. (UIs with basic shapes) Thats true. devdraw prepares its images using memdraw and memlayer. After c= ombining those images we get the results on the display. The moment you do rendering inside your application you have to transfer im= ages using loadimage and flashimage. There is no message inside devdraw whi= ch makes it possible to use images from a client process without copying th= em into the memlayer infrastructure.=20 On Friday, 28 January 2022, at 3:11 PM, Philip Silva wrote: > Also I wonder what kind of functions it should be providing. This intermediate or alternative layer should only add putimage switchbuffe= rs supported by shared memory segments. At least there should be two buffer= s one foreground and one background buffer directly writeable by the client. One simple way to realize this would be enhancing devdraw with one single p= rotocol which would render a client side image from shared memory (segments= ).=20 You can quite now create memimages but if you realize the rendering you hav= e to use loadimage and flushimage each time your images change. devdraw is not slow but it can be made faster with only one extra protocol = which is missing.=20 Enhancing devdraw this way would also solve the problem but not touching de= vdraw and offering an intermediate level between the graphics driver and de= vdraw wouldn't break anything. In the end devdraw also transfers its image = to the videocard one way or the other. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Mbe750= adf3a20ec4a7f7c7b5d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --16433836781.FaFfE5.34398 Date: Fri, 28 Jan 2022 10:27:58 -0500 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, 28 January 2022, at 3:11 PM, Philip= Silva wrote:
I didn't deep-dive y= et into the internals of it, but isn't it that when combining the image= s at the end, that transfer of the initial images with lots of data basical= ly happens only once? It seems to me devdraw can be quite performant on cer= tain use cases. (UIs with basic shapes)

=
Thats true. devdraw prepares its images using memdraw and memlayer. Af= ter combining those images we get the results on the display.

The moment you do rendering inside your application you= have to transfer images using loadimage and flashimage. There is no messag= e inside devdraw which makes it possible to use images from a client proces= s without copying them into the memlayer infrastructure.
<= br />
On Friday, 28 January 2022, at 3:11 PM, Philip Silva wrote:=
Also I wonder what kind of functions = it should be providing.
This intermediate or alterna= tive layer should only add putimage switchbuffers supported by shared memor= y segments. At least there should be two buffers one foreground and one bac= kground buffer directly writeable by the client.

One simple way to realize this would be enhancing devdraw with one s= ingle protocol which would render a client side image from shared memory (s= egments).

You can quite now create memima= ges but if you realize the rendering you have to use loadimage and flushima= ge each time your images change.


devdraw is not slow but it can be made faster with only one extra p= rotocol which is missing.

Enhancing devdr= aw this way would also solve the problem but not touching devdraw and offer= ing an intermediate level between the graphics driver and devdraw wouldn= 9;t break anything. In the end devdraw also transfers its image to the vide= ocard one way or the other.

= --16433836781.FaFfE5.34398--