From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.oboj.net ([195.178.185.14]) by ewsd; Sat May 23 16:10:42 EDT 2020 Received: from localhost (localhost [127.0.0.1]) by mail.oboj.net (Postfix) with ESMTP id A54F0BC54F8; Sat, 23 May 2020 22:10:26 +0200 (CEST) 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 663tPWq8z-jF; Sat, 23 May 2020 22:10:23 +0200 (CEST) Received: from www.oboj.net (unknown [195.178.185.23]) by mail.oboj.net (Postfix) with ESMTP id D3246BC7B93; Sat, 23 May 2020 22:10:21 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Sat, 23 May 2020 23:10:21 +0300 From: jamos@oboj.net To: 9front@9front.org Cc: kokamoto@hera.eonet.ne.jp Subject: Re: [9front] netsurf native frontend In-Reply-To: References: Message-ID: X-Sender: jamos@oboj.net User-Agent: Roundcube Webmail/1.3.4 Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: encrypted encrypted out-scaling ORM grid strategy wrapper Kenji, Philippe=E2=80=99s new native netsurf frontend is a big step forward. It = uses=20 the same core components and libraries as nsfb, but has a GUI using the=20 plan 9 drawing primitives directly, as well as the plan 9 event and font=20 handling. A native frontend has much more control over what happens, and=20 it is possible to layout components in the browser as we wish, e.g.=20 having plan 9 style scrollbars. The framebuffer frontend in Netsurf has its own plotting functions that=20 modifies a memory bitmap, and the plan 9 framebuffer driver (surface)=20 then synchonises that bitmap with a Plan 9 window Image using=20 loadimage() - for the updated area. The framebuffer frontend is foremost=20 designed to run close to hardware, like embedded systems, or on a=20 graphics console. It polls for events once a second, which makes the UI=20 a bit unresponsive, and also consumes a bit more cpu cycles when nothing=20 happens. It also has its internal event handling mechanism that doesn=E2=80= =99t=20 map 1:1 to the one in plan 9. Netsurf=E2=80=99s native frontends generally have much more functionality= than=20 the framebuffer frontend (which is more fixed), and they are designed to=20 integrate with higher-level functions exported by operating system. The=20 framebuffer frontend has a lot of built-in functionality, such as basic=20 font handling, which made it an easier target to start with. The Plan 9 frontend will (if things go well) become one of the Netsurf=E2= =80=99s=20 official frontends, living in its own directory, side by side with other=20 native frontends for Amiga, Atari ST, BeOS/Haiku, Unix, RiscOS, and=20 Windows. Being closer to the upstream, also means that it will be easier=20 to keep up with upcoming tip changes, benefitting, for example, from=20 improved rendering and javascript support. It is an advantage that we now have two frontends for plan 9, as they=20 can be compared both visually and performance wise. I've already noticed=20 that the native frontend is much quicker if you rcpu to another machine=20 and run the browser from there. Jonas On 2020-05-23 07:08, kokamoto@hera.eonet.ne.jp wrote: >> would like to have some feedback on this. >=20 > I don't know why you implemented this, what was your > dislike point of the framebuffer netsurf? >=20 > By the way, I can input =E6=97=A5=E6=9C=AC=E8=AA=9E(Japanese) into the = google > search window of the opening panel, without to compile > for freetype Japanese fonts. >=20 > Kenji