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 23408 invoked from network); 28 Jan 2022 12:21:38 -0000 Received: from tb-ob1.topicbox.com (64.147.108.173) by inbox.vuxu.org with ESMTPUTF8; 28 Jan 2022 12:21:38 -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 F3CAF33148 for ; Fri, 28 Jan 2022 07:21:36 -0500 (EST) (envelope-from bounce.mMeea8f954e2d142447d743e3f.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id F104813F1CD9; Fri, 28 Jan 2022 07:21:36 -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=M48GjSHTwoVY3kwYPmz6xKEHH9pc4dOWuZ6lLRl1kh4=; b=j5rFO1npP2m+ wpf+F83R2vaXVc1c9f96NSBtU8gqPekedl0VJXNUb6FcSkBFBWqorW1+ascin78T eoCKH12NyKo+kOidqo4iG/DrSxEgmfGcpEZhV7H+TGwL/83pVW35CCp5eoA9K+xq 1LaDGZFwnineEZxQlvGjtPtbrT8akfI= To: 9fans <9fans@9fans.net> Subject: Re: [9fans] suggestion : new service targets for plan9 Message-Id: <16433724910.4fa96.617630@composer.9fans.topicbox.com> References: <16433354030.97ACA3.134633@composer.9fans.topicbox.com> <1942de7a-1126-7600-3b36-69ce2effd610@fjrhome.net> In-Reply-To: <1942de7a-1126-7600-3b36-69ce2effd610@fjrhome.net> Date: Fri, 28 Jan 2022 07:21:31 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=16433724911.A7BAd0.617630 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: d3c46758-8034-11ec-9ca8-8ecc2a2d11b0 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UMjUxOGY5ZTRmYzEwZWQwMy1NZWVhOGY5NTRlMmQxNDI0NDdkNzQz?= =?UTF-8?B?ZTNmPg==?= 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:Meea8f954e2d142447d743e3f:1:WB7vvqHG5sopiIYkzgoGS0YQiJOqIuJ4liWxbt0rFSQ --16433724911.A7BAd0.617630 Date: Fri, 28 Jan 2022 07:21:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, 28 January 2022, at 10:55 AM, Frank D. Engel, Jr. wrote: > As far as I can tell this would require practically zero core changes to the system as it is built entirely on existing primitives already offered. What you are suggesting is a higher level filesystem and libdraw combined w= ith the panel library is implemented in a comparable way. This results in d= ecrease of performance. Because the renderer has to read all the files for = all visible regions on the screen and combine them for the display image. memdraw and memlayer which are used by devdraw are doing a similar job the= y combine image memory layers to form the resulting display image. What I suggest is a lower level interface to use the framebuffer directly a= nd I think devdraw (memdraw, memlayer) is too high level and rio oriented. = If you use devdraw as a framebuffer than the only functions you need from d= evdraw are initdraw, loadimage and flushimage which internally use memdraw = and memlayer in a way that decreases performance. Also the transfer of imag= es in this way is expensive (regarding time) a screen image is at least cop= ied two times. So by defining a lower level we could improve the performanc= e of rendering by a factor of two.=20 ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Meea8f= 954e2d142447d743e3f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --16433724911.A7BAd0.617630 Date: Fri, 28 Jan 2022 07:21:31 -0500 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, 28 January 2022, at 10:55 AM, Frank= D. Engel, Jr. wrote:

As far as I c= an tell this would require practically zero core changes to the system as it is built entirely on existing primitives already offered.


W= hat you are suggesting is a higher level filesystem and libdraw combined wi= th the panel library is implemented in a comparable way. This results in de= crease of performance. Because the renderer has to read all the files for a= ll visible regions on the screen and combine them for the display image.

memdraw and memlayer which are used by devd= raw are doing a similar job they combine image memory layers to form the re= sulting display image.

What I suggest is a= lower level interface to use the framebuffer directly and I think devdraw = (memdraw, memlayer) is too high level and rio oriented. If you use devdraw = as a framebuffer than the only functions you need from devdraw are initdraw= , loadimage and flushimage which internally use memdraw and memlayer in a w= ay that decreases performance. Also the transfer of images in this way is e= xpensive (regarding time) a screen image is at least copied two times. So b= y defining a lower level we could improve the performance of rendering by a= factor of two.

= --16433724911.A7BAd0.617630--