From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.oboj.net ([195.178.185.14]) by ewsd; Wed Feb 5 13:40:22 EST 2020 Received: from localhost (localhost [127.0.0.1]) by mail.oboj.net (Postfix) with ESMTP id CCDDDBF3BC8; Wed, 5 Feb 2020 19:40:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.oboj.net Received: from mail.oboj.net ([127.0.0.1]) by localhost (mail.oboj.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGw6p6a6hfbF; Wed, 5 Feb 2020 19:40:14 +0100 (CET) Received: from www.oboj.net (unknown [195.178.185.23]) by mail.oboj.net (Postfix) with ESMTP id 5C33FBF3BAD; Wed, 5 Feb 2020 19:40:14 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 05 Feb 2020 20:40:14 +0200 From: jamos@oboj.net To: 9front@9front.org Cc: knusbaum@sdf.org Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress) In-Reply-To: <4C5612D4AF7609010D965A87B085FAA1@sdf.org> References: <4C5612D4AF7609010D965A87B085FAA1@sdf.org> Message-ID: X-Sender: jamos@oboj.net User-Agent: Roundcube Webmail/1.3.4 List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: distributed rich-client-based property just-in-time API callback app I have now taken a look at your patch. The problem is that you send the whole image to libdraw every time, even if there is only a small update. I did that in an earlier version too, and it was also very slow if running remotely. E.g. only to draw the "back" and "forward" icon generates 2 MB of data each (if window is 800x600). The function copy_image_part() makes a copy of the updated rectangle (of the memory buffer) to another memory buffer, so that loadimage() can be done on a smaller portion of the image. You somehow eliminated the copy_image_part() in your patch, which probably doesn't matter performance wise if run locally, but makes it slower on a LAN and quite much slower on a WAN. I started on some code to also compress the image if it is larger than an certain size, and use cloadimage() for them, but I haven't got around to finish it. I think it would be possible to combine your patch with the earlier copy_image_part() - or something similar, to get both the resizeability and the less network traffic. If the goal is to implement a native frontend for Plan 9, it might not be super important to put too much work optimising the framebuffer driver, but I think the "copy only the updated part" is worth it, and maybe even the compressing part, as most part of a webpage would be quite compressable. Jonas On 2020-02-05 19:44, Kyle Nusbaum wrote: > Thanks, Jonas. > > I wouldn't expect the framebuffer patch to be so much slower, > but hopefully it's a silly mistake or some unnecessary draw calls > that can be eliminated. I'll take another look and see if anything > stands out. > > -- Kyle