From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.oboj.net ([195.178.185.14]) by ewsd; Sat Jan 4 07:08:26 EST 2020 Received: from localhost (localhost [127.0.0.1]) by mail.oboj.net (Postfix) with ESMTP id C2FC0BECBBA; Sat, 4 Jan 2020 13:08:16 +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 lpL2jLVomzm8; Sat, 4 Jan 2020 13:08:16 +0100 (CET) Received: from www.oboj.net (unknown [195.178.185.23]) by mail.oboj.net (Postfix) with ESMTP id EFDCDBECBB9; Sat, 4 Jan 2020 13:08:15 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 04 Jan 2020 14:08:15 +0200 From: jamos@oboj.net To: 9front@9front.org Cc: ori@eigenstate.org Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress) In-Reply-To: <84247256F02174D48607DE3E6E63F615@eigenstate.org> References: <84247256F02174D48607DE3E6E63F615@eigenstate.org> Message-ID: <51d670c2844e84c0421ad91eeb709ac6@oboj.net> X-Sender: jamos@oboj.net User-Agent: Roundcube Webmail/1.3.4 List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: rich-client-based high-performance event-oriented layer Thank you all for all your feedback, and especially Ori for finding the drawing bug! I wonder whether the coordinates that are sent to the plan9_update() function is to be able only to redraw the "damaged" or updated area of browser window, which might result in better drawing performance. I assume that is what you mean with "strided" image? I agree that optimisation of the framebuffer driver might not be worth-while, if the goal is to implement a native frontend in the end. Also thanks for noticing the race in the mk file. I don't feel I have a good enough understanding on them, and if someone with more mkfile experience would like to overhaul them, that would be welcome. The tests for the libnsfb was where I started the project and at that time I didn't cross-compile, so the clean target is also too stupid and easily leaves debris (thus the leftover arm binaries). Kyle, I will look into the mouse coordinate issue. It's very possible that the other framebuffer surfaces that I looked at uses coordinates relative to the window. I think that the rio way of handling coordinates is a bit unique. I didn't focus much on user input so far. For fetching web pages from the network there might be, as many of you have started to discuss, many different possibilities. One solution would be to make 'curl' work, as it is the method used by mainline Netsurf, and as it already ported to 9front, at least it is in /sys/ports. But it has a lot of dependencies, and I think that the option to use 'webfs' definitely is more elegant, if it can be made. My port does right now only use standard APE, and not libgnu in ports, which I think is good thing (the header files of libgnu are really a scary GNU spaghetti). I fully agree that hosting the project on a git/hg repository would be great, and make it easier to work on togehter. Merging with the official Netsurf tree would also be a very nice thing, as keeping up-to-date would be much easier. But in the current port, I don't at all use their build system, which might be unpopular with the maintainers, or hard to keep in sync generally. I am subscribed to the netsurf mailing lists, and will write them about the existence of the new Plan 9 port. It is extra nice now that it not only runs, but also renders webpages! I'll shortly update the tar-file with the driver-fix and the better mkfile for framebuffer test. For repository, maybe I should make myself a github or bitbucket account and put it there to start with? Thank you all, for debugging, comments and discussion! Jonas Amoson