From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mx.sdf.org ([205.166.94.20]) by ewsd; Wed Feb  5 13:54:55 EST 2020
Received: from rustbucket.hsd1.il.comcast.net. (c-98-212-152-230.hsd1.il.comcast.net [98.212.152.230])
	(authenticated (0 bits))
	by mx.sdf.org (8.15.2/8.14.5) with ESMTPSA id 015IstZK024183
	(using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128 bits) verified NO)
	for <9front@9front.org>; Wed, 5 Feb 2020 18:54:56 GMT
Message-ID: <0E573F56E42D91616CAF7AC266E7AE75@sdf.org>
To: 9front@9front.org
Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)
From: Kyle Nusbaum <knusbaum@sdf.org>
Date: Wed, 5 Feb 2020 13:06:43 -0600
In-Reply-To: <fc492aa90120b98cbbc6078bfc440afc@oboj.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: template-oriented SSL over JSON content-driven browser-oriented generator 

> 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.

I see. I'll go back and see if I can get copy_image_part back in.

> 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.

I agree. Especially since you already had it working, it shouldn't be too difficult
to merge it with my patch.

> 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