Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[kokamoto]

Wao!
Thunks Kyle.
Yes, it works for world wide web sites!

It's a bit slow to fetch the outside web page, and the verical scroll bar
just move only when the mouse is on, which may be not so good.

Your disfix.patch made my netsurf showing garbage screen.

Kenji

By the way, arm (3B) is too much slow to compile this.
I found cpu command is very powerfull again.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

> Wao!
> Thunks Kyle.
> Yes, it works for world wide web sites!

Great! Glad someone else has it running.

> 
> It's a bit slow to fetch the outside web page, and the verical scroll bar
> just move only when the mouse is on, which may be not so good.

The disfix patch adds support for scroll wheel.

> Your disfix.patch made my netsurf showing garbage screen.

Hmm were you sure to pipe the standard output and standard error?

Try:
6.nsfb >/dev/null >[2=1]

> Kenji
> 
> By the way, arm (3B) is too much slow to compile this.
> I found cpu command is very powerfull again.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

Hi Kyle!

This is awesome! The browser now fetches pages from the web :-)

The patch for the plan9 framebuffer driver is also cool,
but I notice that it makes things _much_ slower when I
run the program remotely. The time to load the welcome
page was 20 seconds before the disfix patch, and 8.5 minutes
when applied. Then I am running the executable on a
machine somewhere on the internet and display the window
on my terminal. I will look at your patch in detail later!

Very much thanks for the work, a milestone!

Jonas



On 2020-02-05 04:28, Kyle Nusbaum wrote:

>> Wao!
>> Thunks Kyle.
>> Yes, it works for world wide web sites!
> 
> Great! Glad someone else has it running.
> 
>> It's a bit slow to fetch the outside web page, and the verical scroll 
>> bar
>> just move only when the mouse is on, which may be not so good.
> 
> The disfix patch adds support for scroll wheel.
> 
>> Your disfix.patch made my netsurf showing garbage screen.
> 
> Hmm were you sure to pipe the standard output and standard error?
> 
> Try:
> 6.nsfb >/dev/null >[2=1]
> 
>> Kenji
>> 
>> By the way, arm (3B) is too much slow to compile this.
>> I found cpu command is very powerfull again.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]

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

[-- Attachment #2: Type: message/rfc822, Size: 2474 bytes --]

From: jamos@oboj.net
To: 9front@9front.org
Cc: Kyle Nusbaum <knusbaum@sdf.org>
Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)
Date: Wed, 05 Feb 2020 12:00:13 +0200
Message-ID: <9eeeba09fc4c6741e6ef4c691f904695@oboj.net>

Hi Kyle!

This is awesome! The browser now fetches pages from the web :-)

The patch for the plan9 framebuffer driver is also cool,
but I notice that it makes things _much_ slower when I
run the program remotely. The time to load the welcome
page was 20 seconds before the disfix patch, and 8.5 minutes
when applied. Then I am running the executable on a
machine somewhere on the internet and display the window
on my terminal. I will look at your patch in detail later!

Very much thanks for the work, a milestone!

Jonas



On 2020-02-05 04:28, Kyle Nusbaum wrote:

>> Wao!
>> Thunks Kyle.
>> Yes, it works for world wide web sites!
> 
> Great! Glad someone else has it running.
> 
>> It's a bit slow to fetch the outside web page, and the verical scroll 
>> bar
>> just move only when the mouse is on, which may be not so good.
> 
> The disfix patch adds support for scroll wheel.
> 
>> Your disfix.patch made my netsurf showing garbage screen.
> 
> Hmm were you sure to pipe the standard output and standard error?
> 
> Try:
> 6.nsfb >/dev/null >[2=1]
> 
>> Kenji
>> 
>> By the way, arm (3B) is too much slow to compile this.
>> I found cpu command is very powerfull again.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

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

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Eli Cohen]

hey, I just tried to run the "fetch clone" script after adding my ssh
key and I am now getting this error message on each repository:

/bin/git/branch: branch does not exist: refs/heads/plan9

On Wed, Feb 5, 2020 at 10:41 AM <jamos@oboj.net> wrote:
>
> 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



-- 
http://echoline.org

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

[-- Attachment #1: Type: text/plain, Size: 65 bytes --]

I ran into the same issue. Updating git9 fixed the issue for me.

[-- Attachment #2: Type: message/rfc822, Size: 4658 bytes --]

From: Eli Cohen <echoline@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)
Date: Wed, 5 Feb 2020 10:48:01 -0800
Message-ID: <CAHwi9bzS1dgSgyUQdW8HUWzWgPs30GQwG9mC+7Wcm6huy9uZdA@mail.gmail.com>

hey, I just tried to run the "fetch clone" script after adding my ssh
key and I am now getting this error message on each repository:

/bin/git/branch: branch does not exist: refs/heads/plan9

On Wed, Feb 5, 2020 at 10:41 AM <jamos@oboj.net> wrote:
>
> 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



-- 
http://echoline.org

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

> 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

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> hey, I just tried to run the "fetch clone" script after adding my ssh
> key and I am now getting this error message on each repository:
> 
> /bin/git/branch: branch does not exist: refs/heads/plan9

I can't reproduce. Have you updated your git to the latest?
There were a few bugs that I fixed since we started working
on this.

The current version is 9bcfa173b66507cf728023aedc39f73ec23d246a

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

[-- Attachment #1: Type: text/plain, Size: 201 bytes --]

Sorry for my previous, hasty patch.
On closer inspection, it's not hard to incorporate my changes with yours.
Please try out this new patch rather than the old one. It should work much better.

--Kyle

[-- Attachment #2: Type: message/rfc822, Size: 3113 bytes --]

From: jamos@oboj.net
To: 9front@9front.org
Cc: knusbaum@sdf.org
Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)
Date: Wed, 05 Feb 2020 20:40:14 +0200
Message-ID: <fc492aa90120b98cbbc6078bfc440afc@oboj.net>

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

[-- Attachment #3: disfix2.patch --]
[-- Type: text/plain, Size: 6210 bytes --]

--- /mnt/git/branch/heads/plan9/tree/src/surface/plan9.c	Wed Jan 29 13:58:39 2020
+++ src/surface/plan9.c	Wed Feb  5 14:13:38 2020
@@ -31,8 +31,15 @@
 #include <draw.h>
 #include <event.h>
 
-static Image *SrvImage=NULL;	/* Global copy of drawstate->srvimg */
-				/* that is used by eresized() */
+static bool inited;
+static int gwidth;
+static int gheight;
+static bool perform_resize;
+
+static unsigned char *
+create_local_image(int bytes);
+Image *
+create_draw_image(int width, int height, ulong chan);
 
 /*
  * A 'drawstate' contain all information about the
@@ -86,20 +93,75 @@ static int 
 plan9_set_geometry(nsfb_t *nsfb, int width, int height,
 		enum nsfb_format_e format)
 {
+	if(!inited) {
+		fprintf(stderr, "INITING display!\n");
+		if (initdraw(0, 0, "netsurf-fb") < 0){
+			fprintf(stderr, "initdraw failed\n");
+			return -1;
+		}
+		inited=true;
+	}
 	//fprintf(stderr, "DBG: plan9_set_geometry(%d,%d) - check p9copy()!\n",
 	//		width, height);
-
-	if (nsfb->surface_priv != NULL)
-		return -1; /* if were already initialised fail */
 	
 	nsfb->width = width;
 	nsfb->height = height;
 	nsfb->format = format;
 
+	gwidth=width;
+	gheight=height;
+
 	/* select default sw plotters for format */
 	select_plotters(nsfb);
 	nsfb->plotter_fns->copy = p9copy;	/* empty function */
 
+	drawstate_t *drawstate = nsfb->surface_priv;
+
+	/* sanity check bpp. */
+	if ((nsfb->bpp != 32) && (nsfb->bpp != 16) && (nsfb->bpp != 8))
+		return -1;
+
+	if (drawstate == NULL)
+		drawstate = calloc(1, sizeof(drawstate_t));
+	if (drawstate == NULL)
+		return -1;	/* no memory */
+
+	/* create local framebuffer data storage */
+	drawstate->imagebytes =
+		(nsfb->bpp * nsfb->width * nsfb->height) >> 3;
+
+	if(drawstate->localimage) free(drawstate->localimage);
+	drawstate->localimage = calloc(1, drawstate->imagebytes); //create_local_image(drawstate->imagebytes);
+	if(drawstate->updateimage) free(drawstate->updateimage);
+	drawstate->updateimage = calloc(1, drawstate->imagebytes); //create_local_image(drawstate->imagebytes);
+
+	if (drawstate->localimage == NULL || drawstate->updateimage == NULL){
+		fprintf(stderr, "Unable to allocate memory "
+				"for local framebuffer images\n");
+		free(drawstate);
+		return -1;
+		//drawshutdown(); /* to call this? */
+	}
+
+	/* crate a draw image on server side */
+	drawstate->srvimage = create_draw_image(nsfb->width,
+			nsfb->height, XRGB32);
+
+	if (drawstate->srvimage == NULL){
+		fprintf(stderr, "Unable to create an image "
+				"on the display server\n");
+		free(drawstate->localimage);
+		free(drawstate->updateimage);
+		free(drawstate);
+		return -1;
+		//drawshutdown(); /* to call this? */
+	}	
+	
+	/* ensure plotting information is stored */
+	nsfb->surface_priv = drawstate;
+	nsfb->ptr = drawstate->localimage;
+	nsfb->linelen = (nsfb->width * nsfb->bpp) / 8;
+
 	return 0;
 }
 
@@ -107,12 +169,9 @@ plan9_set_geometry(nsfb_t *nsfb, int wid
 void
 eresized(int new)		/* callback also called by libdraw */
 {
+	perform_resize=true;
 	if (new && getwindow(display, Refmesg) < 0)
 		fprintf(stderr,"can't reattach to window");	
-
-	if(SrvImage != NULL)
-		draw(screen, screen->r, SrvImage, nil, ZP);
-	flushimage(display, 1);
 }
 
 /* create_local_image()
@@ -166,65 +225,7 @@ create_draw_image(int width, int height,
 static int
 plan9_initialise(nsfb_t *nsfb)
 {
-	drawstate_t *drawstate = nsfb->surface_priv;
-
-//	fprintf(stderr, "DBG: plan9_initialise()\n");
-
-	if (drawstate != NULL)
-		return -1;	/* already initialised */
-
-	/* sanity check bpp. */
-	if ((nsfb->bpp != 32) && (nsfb->bpp != 16) && (nsfb->bpp != 8))
-		return -1;
-
-	drawstate = calloc(1, sizeof(drawstate_t));
-	if (drawstate == NULL)
-		return -1;	/* no memory */
-	
-	/* initialise the draw graphics in Plan 9 */
-
-	if (initdraw(0, 0, "netsurf-fb") < 0){
-		fprintf(stderr, "initdraw failed\n");
-		return -1;
-	}
 	einit(Emouse|Ekeyboard);
-
-	/* create local framebuffer data storage */
-
-	drawstate->imagebytes =
-		(nsfb->bpp * nsfb->width * nsfb->height) >> 3;
-
-	drawstate->localimage = create_local_image(drawstate->imagebytes);
-	drawstate->updateimage = create_local_image(drawstate->imagebytes);
-
-	if (drawstate->localimage == NULL || drawstate->updateimage == NULL){
-		fprintf(stderr, "Unable to allocate memory "
-				"for local framebuffer images\n");
-		free(drawstate);
-		return -1;
-		//drawshutdown(); /* to call this? */
-	}
-
-	/* crate a draw image on server side */
-	drawstate->srvimage = create_draw_image(nsfb->width,
-			nsfb->height, XRGB32);
-	SrvImage = drawstate->srvimage;		/* global copy for eresized() */
-
-	if (drawstate->srvimage == NULL){
-		fprintf(stderr, "Unable to create an image "
-				"on the display server\n");
-		free(drawstate->localimage);
-		free(drawstate->updateimage);
-		free(drawstate);
-		return -1;
-		//drawshutdown(); /* to call this? */
-	}	
-	
-	/* ensure plotting information is stored */
-	nsfb->surface_priv = drawstate;
-	nsfb->ptr = drawstate->localimage;
-	nsfb->linelen = (nsfb->width * nsfb->bpp) / 8;
-
 	eresized(0);	/* first drawing */
 	return 0;
 }
@@ -385,6 +386,16 @@ trans_plan9_event(nsfb_t *nsfb, nsfb_eve
 				nsevent->type = NSFB_EVENT_KEY_UP;
 			button_changes++;
 		}
+		if(evp->mouse.buttons & 8) {
+			nsevent->value.keycode = NSFB_KEY_MOUSE_4;
+			nsevent->type = NSFB_EVENT_KEY_DOWN;
+			button_changes++;
+		}
+		if(evp->mouse.buttons & 16) {
+			nsevent->value.keycode = NSFB_KEY_MOUSE_5;
+			nsevent->type = NSFB_EVENT_KEY_DOWN;
+			button_changes++;
+		}
 		/* save new button status, for next event to compare with */
 		drawstate->mousebuttons = evp->mouse.buttons;
 
@@ -432,6 +443,16 @@ debug_event(nsfb_event_t *nsevent, Event
 
 static bool plan9_input(nsfb_t *nsfb, nsfb_event_t *nsevent, int timeout)
 {
+	if(perform_resize) {
+		perform_resize=false;
+		int w = screen->r.max.x - screen->r.min.x;
+		int h = screen->r.max.y - screen->r.min.y;
+		fprintf(stderr, "RESIZE_EVENT.\n");
+		nsevent->type = NSFB_EVENT_RESIZE;
+		nsevent->value.resize.w = w;
+		nsevent->value.resize.h = h;
+		return true;
+	}
 	drawstate_t *drawstate = nsfb->surface_priv;
 //	static int once = 0;	/* ensure etimer() is only called once */
 	int e;			/* type of event */

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

Oops. One error in there.
This fixes it:

--- /mnt/git/branch/heads/disfix2/tree/src/surface/plan9.c	Wed Feb  5 14:18:04 2020
+++ src/surface/plan9.c	Wed Feb  5 14:51:10 2020
@@ -113,7 +113,7 @@ plan9_set_geometry(nsfb_t *nsfb, int wid
 
 	/* select default sw plotters for format */
 	select_plotters(nsfb);
-	nsfb->plotter_fns->copy = p9copy;	/* empty function */
+	//nsfb->plotter_fns->copy = p9copy;	/* empty function */
 
 	drawstate_t *drawstate = nsfb->surface_priv;

[-- Attachment #2: Type: message/rfc822, Size: 11126 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 201 bytes --]

Sorry for my previous, hasty patch.
On closer inspection, it's not hard to incorporate my changes with yours.
Please try out this new patch rather than the old one. It should work much better.

--Kyle

[-- Attachment #2.1.2: Type: message/rfc822, Size: 3113 bytes --]

From: jamos@oboj.net
To: 9front@9front.org
Cc: knusbaum@sdf.org
Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)
Date: Wed, 05 Feb 2020 20:40:14 +0200
Message-ID: <fc492aa90120b98cbbc6078bfc440afc@oboj.net>

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

[-- Attachment #2.1.3: disfix2.patch --]
[-- Type: text/plain, Size: 6210 bytes --]

--- /mnt/git/branch/heads/plan9/tree/src/surface/plan9.c	Wed Jan 29 13:58:39 2020
+++ src/surface/plan9.c	Wed Feb  5 14:13:38 2020
@@ -31,8 +31,15 @@
 #include <draw.h>
 #include <event.h>
 
-static Image *SrvImage=NULL;	/* Global copy of drawstate->srvimg */
-				/* that is used by eresized() */
+static bool inited;
+static int gwidth;
+static int gheight;
+static bool perform_resize;
+
+static unsigned char *
+create_local_image(int bytes);
+Image *
+create_draw_image(int width, int height, ulong chan);
 
 /*
  * A 'drawstate' contain all information about the
@@ -86,20 +93,75 @@ static int 
 plan9_set_geometry(nsfb_t *nsfb, int width, int height,
 		enum nsfb_format_e format)
 {
+	if(!inited) {
+		fprintf(stderr, "INITING display!\n");
+		if (initdraw(0, 0, "netsurf-fb") < 0){
+			fprintf(stderr, "initdraw failed\n");
+			return -1;
+		}
+		inited=true;
+	}
 	//fprintf(stderr, "DBG: plan9_set_geometry(%d,%d) - check p9copy()!\n",
 	//		width, height);
-
-	if (nsfb->surface_priv != NULL)
-		return -1; /* if were already initialised fail */
 	
 	nsfb->width = width;
 	nsfb->height = height;
 	nsfb->format = format;
 
+	gwidth=width;
+	gheight=height;
+
 	/* select default sw plotters for format */
 	select_plotters(nsfb);
 	nsfb->plotter_fns->copy = p9copy;	/* empty function */
 
+	drawstate_t *drawstate = nsfb->surface_priv;
+
+	/* sanity check bpp. */
+	if ((nsfb->bpp != 32) && (nsfb->bpp != 16) && (nsfb->bpp != 8))
+		return -1;
+
+	if (drawstate == NULL)
+		drawstate = calloc(1, sizeof(drawstate_t));
+	if (drawstate == NULL)
+		return -1;	/* no memory */
+
+	/* create local framebuffer data storage */
+	drawstate->imagebytes =
+		(nsfb->bpp * nsfb->width * nsfb->height) >> 3;
+
+	if(drawstate->localimage) free(drawstate->localimage);
+	drawstate->localimage = calloc(1, drawstate->imagebytes); //create_local_image(drawstate->imagebytes);
+	if(drawstate->updateimage) free(drawstate->updateimage);
+	drawstate->updateimage = calloc(1, drawstate->imagebytes); //create_local_image(drawstate->imagebytes);
+
+	if (drawstate->localimage == NULL || drawstate->updateimage == NULL){
+		fprintf(stderr, "Unable to allocate memory "
+				"for local framebuffer images\n");
+		free(drawstate);
+		return -1;
+		//drawshutdown(); /* to call this? */
+	}
+
+	/* crate a draw image on server side */
+	drawstate->srvimage = create_draw_image(nsfb->width,
+			nsfb->height, XRGB32);
+
+	if (drawstate->srvimage == NULL){
+		fprintf(stderr, "Unable to create an image "
+				"on the display server\n");
+		free(drawstate->localimage);
+		free(drawstate->updateimage);
+		free(drawstate);
+		return -1;
+		//drawshutdown(); /* to call this? */
+	}	
+	
+	/* ensure plotting information is stored */
+	nsfb->surface_priv = drawstate;
+	nsfb->ptr = drawstate->localimage;
+	nsfb->linelen = (nsfb->width * nsfb->bpp) / 8;
+
 	return 0;
 }
 
@@ -107,12 +169,9 @@ plan9_set_geometry(nsfb_t *nsfb, int wid
 void
 eresized(int new)		/* callback also called by libdraw */
 {
+	perform_resize=true;
 	if (new && getwindow(display, Refmesg) < 0)
 		fprintf(stderr,"can't reattach to window");	
-
-	if(SrvImage != NULL)
-		draw(screen, screen->r, SrvImage, nil, ZP);
-	flushimage(display, 1);
 }
 
 /* create_local_image()
@@ -166,65 +225,7 @@ create_draw_image(int width, int height,
 static int
 plan9_initialise(nsfb_t *nsfb)
 {
-	drawstate_t *drawstate = nsfb->surface_priv;
-
-//	fprintf(stderr, "DBG: plan9_initialise()\n");
-
-	if (drawstate != NULL)
-		return -1;	/* already initialised */
-
-	/* sanity check bpp. */
-	if ((nsfb->bpp != 32) && (nsfb->bpp != 16) && (nsfb->bpp != 8))
-		return -1;
-
-	drawstate = calloc(1, sizeof(drawstate_t));
-	if (drawstate == NULL)
-		return -1;	/* no memory */
-	
-	/* initialise the draw graphics in Plan 9 */
-
-	if (initdraw(0, 0, "netsurf-fb") < 0){
-		fprintf(stderr, "initdraw failed\n");
-		return -1;
-	}
 	einit(Emouse|Ekeyboard);
-
-	/* create local framebuffer data storage */
-
-	drawstate->imagebytes =
-		(nsfb->bpp * nsfb->width * nsfb->height) >> 3;
-
-	drawstate->localimage = create_local_image(drawstate->imagebytes);
-	drawstate->updateimage = create_local_image(drawstate->imagebytes);
-
-	if (drawstate->localimage == NULL || drawstate->updateimage == NULL){
-		fprintf(stderr, "Unable to allocate memory "
-				"for local framebuffer images\n");
-		free(drawstate);
-		return -1;
-		//drawshutdown(); /* to call this? */
-	}
-
-	/* crate a draw image on server side */
-	drawstate->srvimage = create_draw_image(nsfb->width,
-			nsfb->height, XRGB32);
-	SrvImage = drawstate->srvimage;		/* global copy for eresized() */
-
-	if (drawstate->srvimage == NULL){
-		fprintf(stderr, "Unable to create an image "
-				"on the display server\n");
-		free(drawstate->localimage);
-		free(drawstate->updateimage);
-		free(drawstate);
-		return -1;
-		//drawshutdown(); /* to call this? */
-	}	
-	
-	/* ensure plotting information is stored */
-	nsfb->surface_priv = drawstate;
-	nsfb->ptr = drawstate->localimage;
-	nsfb->linelen = (nsfb->width * nsfb->bpp) / 8;
-
 	eresized(0);	/* first drawing */
 	return 0;
 }
@@ -385,6 +386,16 @@ trans_plan9_event(nsfb_t *nsfb, nsfb_eve
 				nsevent->type = NSFB_EVENT_KEY_UP;
 			button_changes++;
 		}
+		if(evp->mouse.buttons & 8) {
+			nsevent->value.keycode = NSFB_KEY_MOUSE_4;
+			nsevent->type = NSFB_EVENT_KEY_DOWN;
+			button_changes++;
+		}
+		if(evp->mouse.buttons & 16) {
+			nsevent->value.keycode = NSFB_KEY_MOUSE_5;
+			nsevent->type = NSFB_EVENT_KEY_DOWN;
+			button_changes++;
+		}
 		/* save new button status, for next event to compare with */
 		drawstate->mousebuttons = evp->mouse.buttons;
 
@@ -432,6 +443,16 @@ debug_event(nsfb_event_t *nsevent, Event
 
 static bool plan9_input(nsfb_t *nsfb, nsfb_event_t *nsevent, int timeout)
 {
+	if(perform_resize) {
+		perform_resize=false;
+		int w = screen->r.max.x - screen->r.min.x;
+		int h = screen->r.max.y - screen->r.min.y;
+		fprintf(stderr, "RESIZE_EVENT.\n");
+		nsevent->type = NSFB_EVENT_RESIZE;
+		nsevent->value.resize.w = w;
+		nsevent->value.resize.h = h;
+		return true;
+	}
 	drawstate_t *drawstate = nsfb->surface_priv;
 //	static int once = 0;	/* ensure etimer() is only called once */
 	int e;			/* type of event */

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> It spends for getting https://www.netsurf-browser.org/ about 22 secs
> on my rpi-3B terminal.
> On the other hand, abaco or mothra get it within 2 seconds.
> Those latters are rolling paper model, and page looking is much
> better in netsurf though.

Yes, right now netsurf is extremely slow. I don't think anyone
has looked into it yet: we haven't even gotten it working properly,
it's too early to worry about optimizing.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[kokamoto]

It spends for getting https://www.netsurf-browser.org/ about 22 secs
on my rpi-3B terminal.
On the other hand, abaco or mothra get it within 2 seconds.
Those latters are rolling paper model, and page looking is much
better in netsurf though.

Kenji

>> why cache at all?
> 
> Fair enough. I haven't benchmarked enough to know if it'll help.
> 
> However, assuming it does, the question is whether there's an
> objection to pushing it into webfs instead of doing it in the
> browser. That affects a few design decisions.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Steve Simon]

i did tests years ago, with abaco (that long ago) and the win was huge.

don't forget this is not a proxy cache but a cache outside the tls encrypted link, you are caching images and html that the page references.

-Steve


> On 6 Feb 2020, at 2:46 pm, hiro <23hiro@gmail.com> wrote:
> 
> @steve: i used to run a caching proxy for all web clients in my
> network, back when there were still multiple web browser vendors and
> the majority of websites (barring the ones where you log in with
> user/pass) still supported plain unencrypted access by default.
> 
> it was great. ad blocking and caching could be done on a beefy central
> machine and everybody around would benefit from it.
> 
> nowadays it has become completely unusable. everything is encrypted
> anyway, and even when i check the way that chrome uses web site
> ressources it seems that the web servers are always so slow anyway
> with providing the main content (which always is small though) that
> the overhead of downloading all the other content over and over again
> isn't so important any more.
> 
> my bandwidth is big. i'm mainly bottlenecked by the javascripts in the
> browser, some sluggish interaction with sliding and fading video
> windows that want to evade my mouse pointer, or the web server's very
> slow processing times.
> 
> even closing tabs nowadays on a modern computer takes longer than
> turning off windows98 safely.
> 
> that's why i ask: why not leave away caching?
> did you do any real tests? :)

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[kokamoto]

> Kenji, you might not see a speed up if you run the browser on your 
> terminal or all-in-one plan9 installation, but if you run it on a 
> cpu-server it makes a difference depending on the bandwidth.

I run it on a pc64 terminal, and yes, it's quick enough.
Thank you very much for your efforts to make this available to us.

When I run it on a arm(rpi 3B) terminal, I see a error at the top
of the welcome page like:
-----
html,body{margin:0:padding:0;}body{color:#000:background:#fff;font-family:sans-serif;margin:0
auto;}:link{text-decoration:underline;color:#00f;}a:visited{text-decoration:underline;color:#60a;}a:hover{text-decoration:none;}a:active{text-decoration:none;}a:active{text-decoration underline;color:#f00;}.
...
p{margin-top:1.5em;padding-top:0.4em;border-top:2px solid #94adff;}
-----

It's a source to <style type="test/css">

BBS News page still make the browser crush.

Kenji

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> why cache at all?

Fair enough. I haven't benchmarked enough to know if it'll help.

However, assuming it does, the question is whether there's an
objection to pushing it into webfs instead of doing it in the
browser. That affects a few design decisions.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[hiro]

@steve: i used to run a caching proxy for all web clients in my
network, back when there were still multiple web browser vendors and
the majority of websites (barring the ones where you log in with
user/pass) still supported plain unencrypted access by default.

it was great. ad blocking and caching could be done on a beefy central
machine and everybody around would benefit from it.

nowadays it has become completely unusable. everything is encrypted
anyway, and even when i check the way that chrome uses web site
ressources it seems that the web servers are always so slow anyway
with providing the main content (which always is small though) that
the overhead of downloading all the other content over and over again
isn't so important any more.

my bandwidth is big. i'm mainly bottlenecked by the javascripts in the
browser, some sluggish interaction with sliding and fading video
windows that want to evade my mouse pointer, or the web server's very
slow processing times.

even closing tabs nowadays on a modern computer takes longer than
turning off windows98 safely.

that's why i ask: why not leave away caching?
did you do any real tests? :)

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

Great! With the latest update of libnsfb/src/surface/plan9.c my drawing 
performance is now back to how it was before. I didn't notice before 
that it was scrolling that triggered p9copy(), but the window now 
redraws much nicer when scrolling :-)

Kenji, you might not see a speed up if you run the browser on your 
terminal or all-in-one plan9 installation, but if you run it on a 
cpu-server it makes a difference depending on the bandwidth.

I still might continue to implement compression of big updates and 
upload them with cloadimage() instead of loadimage() - especially if the 
framebuffer version of netsurf will stick around for some while.

Jonas

On 2020-02-06 02:24, Kyle Nusbaum wrote:

> I'm sorry, that patch had an issue with p9copy.
> 
> However, I've fixed and merged my changes into the repos.
> 
> If you get a clean checkout from nsport, it should compile and work.
> 
> On February 5, 2020 6:08:40 PM CST, kokamoto@hera.eonet.ne.jp wrote:
> 
>> I tried disfix2.patch.
>> It seems not to speed up the drawing...
>> 
>> By the way, BBCNews site makes corrupt the browser.
>> 
>> Kenji
> 
> -- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Steve Simon]

caching really helps a lot.

uriel hacked the labs webfs to crudely add caching, though 9front uses a rewrite of webfs by cinap (much better).

i would suggest a cache should be a separate program but maybe one webfs inserts into its flow, like aan is inserted by import.

i also wondered if a cache could/should make use of a global cache for non-authenticated connections, so all users share the cache for the google homepage but not for their bank. i don't know enough about the web to know if this is feasible.

-Steve


On 6 Feb 2020, at 8:18 am, hiro <23hiro@gmail.com> wrote:
> 
> why cache at all?

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[hiro]

why cache at all?

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> Yes! I've just applied my changes and have it compiling and loading web pages.
> I've just taken the git/diff and dumped it. (That's attached)

So, looking over the changes again -- I have 2 questions:

1) Is the hlcache api a better fit for webfs than llcache?
2) Is caching something we should push down to webfs?

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

I'm sorry, that patch had an issue with p9copy.

However, I've fixed and merged my changes into the repos.

If you get a clean checkout from nsport, it should compile and work.


On February 5, 2020 6:08:40 PM CST, kokamoto@hera.eonet.ne.jp wrote:
>I tried disfix2.patch.
>It seems not to speed up the drawing...
>
>By the way, BBCNews site makes corrupt the browser.
>
>Kenji

-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[kokamoto]

I tried disfix2.patch.
It seems not to speed up the drawing...

By the way, BBCNews site makes corrupt the browser.

Kenji

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[kokamoto]

> After resizing (make smaller window), I cannot enter text from
> keyboard.   However, re-resizing it to a larger widow, I can
> input text again.

Above problem solved after I do
mk 9res
mk install
under nsport/netsurf.

Kenji

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[kokamoto]

> Now, it works perfect, I can resize the window

After resizing (make smaller window), I cannot enter text from
keyboard.   However, re-resizing it to a larger widow, I can
input text again.

By the way, in the Google window of welcome.html,
I cannot use ktrans.  Does it use special input other than
from console?

In other text window, I can use ktrans, though Japanese
font is not loaded.☺

Kenji

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[kokamoto]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

Oh, sorry!

It was my mistake to make patch disfix.patch.
Now, it works perfect, I can resize the window, the vertical
scroll bar works fine, too.

Kenji

PS. I changed the files under /sys/lib/netsurf/, having
the content of ../../../resource/xxxx to copy the real
materials from resources directory

[-- Attachment #2: Type: message/rfc822, Size: 2102 bytes --]

From: Kyle Nusbaum <knusbaum@sdf.org>
To: 9front@9front.org
Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)
Date: Tue, 4 Feb 2020 20:28:15 -0600
Message-ID: <8B10FD7549805AF6F760FED38EA4A012@sdf.org>

> Wao!
> Thunks Kyle.
> Yes, it works for world wide web sites!

Great! Glad someone else has it running.

> 
> It's a bit slow to fetch the outside web page, and the verical scroll bar
> just move only when the mouse is on, which may be not so good.

The disfix patch adds support for scroll wheel.

> Your disfix.patch made my netsurf showing garbage screen.

Hmm were you sure to pipe the standard output and standard error?

Try:
6.nsfb >/dev/null >[2=1]

> Kenji
> 
> By the way, arm (3B) is too much slow to compile this.
> I found cpu command is very powerfull again.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

That was a patch for the netsurf subproject, if that wasn't clear.
Here's one for libnsfb that fixes scrolling and allows resizing.

If you see part of the UI disappearing, it's because I added
code that only redraws necessary parts of the window, and
the stdout/stderr flicker causes issues. If you pipe stdout/stderr 
somewhere else, everything should look ok.

Try resizing the window and let me know.

-- Kyle

[-- Attachment #2: Type: message/rfc822, Size: 1909 bytes --]

From: ori@eigenstate.org
To: knusbaum@sdf.org, kokamoto@hera.eonet.ne.jp, 9front@9front.org
Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)
Date: Tue, 4 Feb 2020 15:58:44 -0800
Message-ID: <8D34CD631EB2A3983305713F243B7430@eigenstate.org>

> Yes! I've just applied my changes and have it compiling and loading web pages.
> I've just taken the git/diff and dumped it. (That's attached)
> 
> The code still contains debugging fprintf and may contain leaks, etc. It's not done, but it's what I
> have at the moment.
> 
> It's kind of a hack, as it hijacks the llcache mechanism, but the higher-level fetcher interface isn't
> really compatible with webfs.
> 
> I also have changes that implement correct scrolling and resizing. I'll try to get those into patch 
> format when I get a chance. Hopefully some time this week.

Nice! Thanks!

I'll be playing around a bit with this tomorrow. From a quick skim,
it feels too intrusive to upstream, but I think we can use it to
start a discussion on the right way to do things.

But we can definitely commit this, and start using it :)

[-- Attachment #3: disfix.patch --]
[-- Type: text/plain, Size: 8800 bytes --]

--- /mnt/git/branch/heads/visfix/tree/src/surface/plan9.c	Wed Jan 29 13:58:39 2020
+++ src/surface/plan9.c	Tue Feb  4 19:13:09 2020
@@ -33,6 +33,12 @@
 
 static Image *SrvImage=NULL;	/* Global copy of drawstate->srvimg */
 				/* that is used by eresized() */
+static bool inited;
+static int gwidth;
+static int gheight;
+static bool perform_resize; /* Used to trigger a resize of the window */
+
+Image *create_draw_image(int width, int height, ulong chan);
 
 /*
  * A 'drawstate' contain all information about the
@@ -69,16 +75,26 @@ mssleep(int ms)		/* sleep milliseconds *
 }
 
 
-/* I am not sure if this routine is needed to be implemented.
- * I think it makes a copy of the display if the resolution is
- * changed on the fly. But I am not sure that is even supported
- * in framebuffer mode
+/*
+ * It's not clear that this is any faster than the default implementation.
+ * I don't see any visible performance change when commenting
+ * nsfb->plotter_fns->copy = p9copy; in plan9_set_geometry
  */
-
 static bool
 p9copy(nsfb_t *nsfb, nsfb_bbox_t *srcbox, nsfb_bbox_t *dstbox)
 {
-    return true;
+	Point srcpt;
+	srcpt.x=srcbox->x0 + screen->r.min.x;
+	srcpt.y=srcbox->y0 + screen->r.min.y;
+
+	Rectangle dstrect;
+	dstrect.min.x = dstbox->x0 + screen->r.min.x;
+	dstrect.min.y = dstbox->y0 + screen->r.min.y;
+	dstrect.max.x = dstbox->x1 + screen->r.min.x;
+	dstrect.max.y = dstbox->y1 + screen->r.min.y;
+
+	draw(screen, dstrect, screen, nil, srcpt);
+	return true;
 }
 
 
@@ -86,19 +102,71 @@ static int 
 plan9_set_geometry(nsfb_t *nsfb, int width, int height,
 		enum nsfb_format_e format)
 {
-	//fprintf(stderr, "DBG: plan9_set_geometry(%d,%d) - check p9copy()!\n",
-	//		width, height);
+	if(!inited) {
+		fprintf(stderr, "INITING display!\n");
+		if (initdraw(0, 0, "netsurf-fb") < 0){
+			fprintf(stderr, "initdraw failed\n");
+			return -1;
+		}
+		inited=true;
+	}
 
-	if (nsfb->surface_priv != NULL)
-		return -1; /* if were already initialised fail */
-	
 	nsfb->width = width;
 	nsfb->height = height;
 	nsfb->format = format;
+	
+	gwidth=width;
+	gheight=height;
 
 	/* select default sw plotters for format */
 	select_plotters(nsfb);
-	nsfb->plotter_fns->copy = p9copy;	/* empty function */
+	nsfb->plotter_fns->copy = p9copy;	
+
+	drawstate_t *drawstate = nsfb->surface_priv;
+
+	/* sanity check bpp. */
+	if ((nsfb->bpp != 32) && (nsfb->bpp != 16) && (nsfb->bpp != 8))
+		return -1;
+
+	if (drawstate == NULL)
+		drawstate = calloc(1, sizeof(drawstate_t));
+	if (drawstate == NULL)
+		return -1;	/* no memory */
+
+	/* create local framebuffer data storage */
+	drawstate->imagebytes =
+		(nsfb->bpp * nsfb->width * nsfb->height) >> 3;
+
+	if(drawstate->localimage) free(drawstate->localimage);
+	drawstate->localimage = calloc(1, drawstate->imagebytes); //create_local_image(drawstate->imagebytes);
+
+	if (drawstate->localimage == NULL){
+		fprintf(stderr, "Unable to allocate memory "
+				"for local framebuffer image\n");
+		free(drawstate);
+		return -1;
+		//drawshutdown(); /* to call this? */
+	}
+
+	/* crate a draw image on server side */
+	if(drawstate->srvimage) freeimage(drawstate->srvimage);
+	drawstate->srvimage = create_draw_image(nsfb->width,
+			nsfb->height, XRGB32);
+	SrvImage = drawstate->srvimage;		/* global copy for eresized() */
+
+	if (drawstate->srvimage == NULL){
+		fprintf(stderr, "Unable to create an image "
+				"on the display server\n");
+		free(drawstate->localimage);
+		free(drawstate);
+		return -1;
+		//drawshutdown(); /* to call this? */
+	}	
+	
+	/* ensure plotting information is stored */
+	nsfb->surface_priv = drawstate;
+	nsfb->ptr = drawstate->localimage;
+	nsfb->linelen = (nsfb->width * nsfb->bpp) / 8;
 
 	return 0;
 }
@@ -107,12 +175,9 @@ plan9_set_geometry(nsfb_t *nsfb, int wid
 void
 eresized(int new)		/* callback also called by libdraw */
 {
+	perform_resize=true;
 	if (new && getwindow(display, Refmesg) < 0)
 		fprintf(stderr,"can't reattach to window");	
-
-	if(SrvImage != NULL)
-		draw(screen, screen->r, SrvImage, nil, ZP);
-	flushimage(display, 1);
 }
 
 /* create_local_image()
@@ -166,66 +231,12 @@ create_draw_image(int width, int height,
 static int
 plan9_initialise(nsfb_t *nsfb)
 {
-	drawstate_t *drawstate = nsfb->surface_priv;
-
-//	fprintf(stderr, "DBG: plan9_initialise()\n");
-
-	if (drawstate != NULL)
-		return -1;	/* already initialised */
-
-	/* sanity check bpp. */
-	if ((nsfb->bpp != 32) && (nsfb->bpp != 16) && (nsfb->bpp != 8))
-		return -1;
-
-	drawstate = calloc(1, sizeof(drawstate_t));
-	if (drawstate == NULL)
-		return -1;	/* no memory */
-	
+	fprintf(stderr, "Starting INITIALISE\n");
 	/* initialise the draw graphics in Plan 9 */
 
-	if (initdraw(0, 0, "netsurf-fb") < 0){
-		fprintf(stderr, "initdraw failed\n");
-		return -1;
-	}
 	einit(Emouse|Ekeyboard);
 
-	/* create local framebuffer data storage */
-
-	drawstate->imagebytes =
-		(nsfb->bpp * nsfb->width * nsfb->height) >> 3;
-
-	drawstate->localimage = create_local_image(drawstate->imagebytes);
-	drawstate->updateimage = create_local_image(drawstate->imagebytes);
-
-	if (drawstate->localimage == NULL || drawstate->updateimage == NULL){
-		fprintf(stderr, "Unable to allocate memory "
-				"for local framebuffer images\n");
-		free(drawstate);
-		return -1;
-		//drawshutdown(); /* to call this? */
-	}
-
-	/* crate a draw image on server side */
-	drawstate->srvimage = create_draw_image(nsfb->width,
-			nsfb->height, XRGB32);
-	SrvImage = drawstate->srvimage;		/* global copy for eresized() */
-
-	if (drawstate->srvimage == NULL){
-		fprintf(stderr, "Unable to create an image "
-				"on the display server\n");
-		free(drawstate->localimage);
-		free(drawstate->updateimage);
-		free(drawstate);
-		return -1;
-		//drawshutdown(); /* to call this? */
-	}	
-	
-	/* ensure plotting information is stored */
-	nsfb->surface_priv = drawstate;
-	nsfb->ptr = drawstate->localimage;
-	nsfb->linelen = (nsfb->width * nsfb->bpp) / 8;
-
-	eresized(0);	/* first drawing */
+	eresized(0);
 	return 0;
 }
 
@@ -385,6 +396,16 @@ trans_plan9_event(nsfb_t *nsfb, nsfb_eve
 				nsevent->type = NSFB_EVENT_KEY_UP;
 			button_changes++;
 		}
+		if(evp->mouse.buttons & 8) {
+			nsevent->value.keycode = NSFB_KEY_MOUSE_4;
+			nsevent->type = NSFB_EVENT_KEY_DOWN;
+			button_changes++;
+		}
+		if(evp->mouse.buttons & 16) {
+			nsevent->value.keycode = NSFB_KEY_MOUSE_5;
+			nsevent->type = NSFB_EVENT_KEY_DOWN;
+			button_changes++;
+		}
 		/* save new button status, for next event to compare with */
 		drawstate->mousebuttons = evp->mouse.buttons;
 
@@ -432,6 +453,17 @@ debug_event(nsfb_event_t *nsevent, Event
 
 static bool plan9_input(nsfb_t *nsfb, nsfb_event_t *nsevent, int timeout)
 {
+	if(perform_resize) {
+		perform_resize=false;
+		int w = screen->r.max.x - screen->r.min.x;
+		int h = screen->r.max.y - screen->r.min.y;
+		fprintf(stderr, "RESIZE_EVENT.\n");
+		nsevent->type = NSFB_EVENT_RESIZE;
+		nsevent->value.resize.w = w;
+		nsevent->value.resize.h = h;
+		return true;
+	}
+
 	drawstate_t *drawstate = nsfb->surface_priv;
 //	static int once = 0;	/* ensure etimer() is only called once */
 	int e;			/* type of event */
@@ -590,36 +622,42 @@ redraw_srvimage(drawstate_t *drawstate)
  */
 
 static int
-update_and_redraw_srvimage(drawstate_t *drawstate, Rectangle r,
-			int width, int height, int bpp)
+update_and_redraw_srvimage(drawstate_t *drawstate, int x, int y,
+		int width, int height)
 {
-	copy_image_part(drawstate->updateimage,
-			drawstate->localimage + buffer_offset(r.min, width, bpp),
-			r, width, bpp);
+	int loaded;
+	Rectangle r;
+	Point pt;
+
+	r.min.x=0;
+	r.min.y=0;
+	r.max.x=gwidth;
+	r.max.y=gheight;
+
+	//fprintf(stderr, "DBG: update_and_redraw_srvimage(x=%d, y=%d "
+	//		"w=%d, h=%d)\n", x, y, width, height);
+
+	loaded = loadimage(drawstate->srvimage, r, drawstate->localimage,
+			drawstate->imagebytes);
+
+	r.min.x=screen->r.min.x+x;
+	r.min.y=screen->r.min.y+y;
+	r.max.x=screen->r.min.x+x+width;
+	r.max.y=screen->r.min.y+y+height;
+
+	pt.x = x;
+	pt.y = y;
+	draw(screen, r, drawstate->srvimage, nil, pt);
+	flushimage(display, 1);
 
-	loadimage(drawstate->srvimage, r, drawstate->updateimage,
-			rect_bytes(r, bpp));
-	
-	redraw_srvimage(drawstate);
 	return 0;
 }
 
 static int plan9_update(nsfb_t *nsfb, nsfb_bbox_t *box)
 {
 	drawstate_t *drawstate = nsfb->surface_priv;
-	Rectangle r;
-
-	r.min.x = box->x0;
-	r.min.y = box->y0;
-	r.max.x = box->x1;
-	r.max.y = box->y1;
-
-//	fprintf(stderr, "DBG: %4d KB update (%3d,%3d) to (%3d, %3d)\n",
-//		(r.max.x-r.min.x)*(r.max.y-r.min.y)*(nsfb->bpp>>3) >> 10,
-//		r.min.x, r.min.y, r.max.x, r.max.y);
-
-	update_and_redraw_srvimage(drawstate, r,
-			nsfb->width, nsfb->height, nsfb->bpp);
+	update_and_redraw_srvimage(drawstate ,box->x0, box->y0,
+			box->x1 - box->x0, box->y1 - box->y0);
 	return 0;
 }
 

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> Yes! I've just applied my changes and have it compiling and loading web pages.
> I've just taken the git/diff and dumped it. (That's attached)
> 
> The code still contains debugging fprintf and may contain leaks, etc. It's not done, but it's what I
> have at the moment.
> 
> It's kind of a hack, as it hijacks the llcache mechanism, but the higher-level fetcher interface isn't
> really compatible with webfs.
> 
> I also have changes that implement correct scrolling and resizing. I'll try to get those into patch 
> format when I get a chance. Hopefully some time this week.

Nice! Thanks!

I'll be playing around a bit with this tomorrow. From a quick skim,
it feels too intrusive to upstream, but I think we can use it to
start a discussion on the right way to do things.

But we can definitely commit this, and start using it :)

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

Yes! I've just applied my changes and have it compiling and loading web pages.
I've just taken the git/diff and dumped it. (That's attached)

The code still contains debugging fprintf and may contain leaks, etc. It's not done, but it's what I
have at the moment.

It's kind of a hack, as it hijacks the llcache mechanism, but the higher-level fetcher interface isn't
really compatible with webfs.

I also have changes that implement correct scrolling and resizing. I'll try to get those into patch 
format when I get a chance. Hopefully some time this week.

[-- Attachment #2: Type: message/rfc822, Size: 1821 bytes --]

From: kokamoto@hera.eonet.ne.jp
To: 9front@9front.org
Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)
Date: Wed, 5 Feb 2020 08:40:21 +0900
Message-ID: <781A1B3FA53B0CDCD43A0D5D8F059442@hera.eonet.ne.jp>

> That works for me. I've not sumbitted patches this way before so correct me if my diffs are not usable.

So, are you going to post the diff here?

Kenji

[-- Attachment #3: webfs.patch --]
[-- Type: text/plain, Size: 23087 bytes --]

--- /mnt/git/branch/heads/plan9/tree/content/llcache.c	Sun Feb  2 19:28:50 2020
+++ content/llcache.c	Tue Feb  4 17:33:22 2020
@@ -52,6 +52,7 @@
 #include "content/fetch.h"
 #include "content/backing_store.h"
 #include "content/urldb.h"
+#include "content/webfs.h"
 
 /**
  * State of a low-level cache object fetch.
@@ -79,6 +80,8 @@ struct llcache_handle {
 
 	llcache_fetch_state state;	/**< Last known state of object fetch */
 	size_t bytes;			/**< Last reported byte count */
+
+	webfs_handle *wh;  /**< Holds a webfs handle if this is a webfs request. */
 };
 
 /**
@@ -3326,6 +3329,8 @@ void llcache_clean(bool purge)
 
 	NSLOG(llcache, DEBUG, "Attempting cache clean");
 
+	webfs_clean(purge);
+
 	/* If the cache is being purged set the size limit to zero. */
 	if (purge) {
 		limit = 0;
@@ -3490,6 +3495,11 @@ void llcache_clean(bool purge)
 nserror
 llcache_initialise(const struct llcache_parameters *prm)
 {
+	nserror err = webfs_initialise(prm);
+	if(err != NSERROR_OK) {
+		return err;
+	}
+
 	llcache = calloc(1, sizeof(struct llcache_s));
 	if (llcache == NULL) {
 		return NSERROR_NOMEM;
@@ -3520,6 +3530,8 @@ void llcache_finalise(void)
 	llcache_object *object, *next;
 	uint64_t total_bandwidth = 0; /* total bandwidth */
 
+	webfs_finalise();
+
 	/* Clean uncached objects */
 	for (object = llcache->uncached_objects; object != NULL; object = next) {
 		llcache_object_user *user, *next_user;
@@ -3632,14 +3644,17 @@ nserror llcache_handle_retrieve(nsurl *u
 	nsurl *hsts_url;
 	bool hsts_in_use;
 
+	fprintf(stderr, "[DBG]: FETCHING URL: %s\n", nsurl_access(url));
+
 	/* Perform HSTS transform */
 	error = llcache_hsts_transform_url(url, &hsts_url, &hsts_in_use);
 	if (error != NSERROR_OK) {
 		return error;
 	}
 
+	char *scheme = lwc_string_data(nsurl_get_component(hsts_url, NSURL_SCHEME));
 	/* Can we fetch this URL at all? */
-	if (fetch_can_fetch(hsts_url) == false) {
+	if (fetch_can_fetch(hsts_url) == false && (strcmp("http", scheme) != 0 && strcmp("https", scheme) != 0)) {
 		nsurl_unref(hsts_url);
 		return NSERROR_NO_FETCH_HANDLER;
 	}
@@ -3651,6 +3666,17 @@ nserror llcache_handle_retrieve(nsurl *u
 		return error;
 	}
 
+	if(strcmp("http", scheme) == 0 || strcmp("https", scheme) == 0) {
+		// THIS IS A WEBFS REQUEST!
+		nserror err = webfs_handle_retrieve(hsts_url, flags, referer, post, cb, pw, user->handle, &user->handle->wh);
+		if(err != NSERROR_OK) {
+			nsurl_unref(hsts_url);
+			return error;
+		}
+		*result = user->handle;
+		return err;
+	}
+
 	/* Retrieve a suitable object from the cache,
 	 * creating a new one if needed. */
 	error = llcache_object_retrieve(hsts_url, flags, referer, post, 0,
@@ -3682,6 +3708,10 @@ nserror llcache_handle_change_callback(l
 	handle->cb = cb;
 	handle->pw = pw;
 
+	if(handle->wh != NULL) {
+		return webfs_handle_change_callback(handle->wh, cb, pw);
+	}
+
 	return NSERROR_OK;
 }
 
@@ -3689,6 +3719,9 @@ nserror llcache_handle_change_callback(l
 /* Exported interface documented in content/llcache.h */
 nserror llcache_handle_release(llcache_handle *handle)
 {
+	if(handle->wh != NULL) {
+		return webfs_handle_release(handle->wh);
+	}
 	nserror error = NSERROR_OK;
 	llcache_object *object = handle->object;
 	llcache_object_user *user = llcache_object_find_user(handle);
@@ -3723,12 +3756,20 @@ nserror llcache_handle_clone(llcache_han
 		*result = newuser->handle;
 	}
 
+	if(handle->wh != NULL) {
+		return webfs_handle_clone(newuser->handle, handle->wh, &newuser->handle->wh);
+	}
+
 	return error;
 }
 
 /* See llcache.h for documentation */
 nserror llcache_handle_abort(llcache_handle *handle)
 {
+	if(handle->wh != NULL) {
+		return webfs_handle_abort(handle->wh);
+	}
+
 	llcache_object_user *user = llcache_object_find_user(handle);
 	llcache_object *object = handle->object, *newobject;
 	nserror error = NSERROR_OK;
@@ -3791,6 +3832,10 @@ nserror llcache_handle_abort(llcache_han
 /* See llcache.h for documentation */
 nserror llcache_handle_force_stream(llcache_handle *handle)
 {
+	if(handle->wh != NULL) {
+		return webfs_handle_force_stream(handle->wh);
+	}
+
 	llcache_object_user *user = llcache_object_find_user(handle);
 	llcache_object *object = handle->object;
 
@@ -3813,6 +3858,10 @@ nserror llcache_handle_force_stream(llca
 /* See llcache.h for documentation */
 nserror llcache_handle_invalidate_cache_data(llcache_handle *handle)
 {
+	if(handle->wh != NULL) {
+		webfs_handle_invalidate_cache_data(handle->wh);
+	}
+
 	if ((handle->object != NULL) &&
 	    (handle->object->fetch.fetch == NULL) &&
 	    (handle->object->cache.no_cache == LLCACHE_VALIDATE_FRESH)) {
@@ -3826,6 +3875,9 @@ nserror llcache_handle_invalidate_cache_
 /* See llcache.h for documentation */
 nsurl *llcache_handle_get_url(const llcache_handle *handle)
 {
+	if(handle->wh != NULL) {
+		return webfs_handle_get_url(handle->wh);
+	}
 	return handle->object != NULL ? handle->object->url : NULL;
 }
 
@@ -3833,6 +3885,10 @@ nsurl *llcache_handle_get_url(const llca
 const uint8_t *llcache_handle_get_source_data(const llcache_handle *handle,
 		size_t *size)
 {
+	if(handle->wh != NULL) {
+		return webfs_handle_get_source_data(handle->wh, size);
+	}
+
 	*size = handle->object != NULL ? handle->object->source_len : 0;
 
 	return handle->object != NULL ? handle->object->source_data : NULL;
@@ -3842,6 +3898,10 @@ const uint8_t *llcache_handle_get_source
 const char *llcache_handle_get_header(const llcache_handle *handle,
 		const char *key)
 {
+	if(handle->wh != NULL) {
+		return webfs_handle_get_header(handle->wh, key);
+	}
+
 	const llcache_object *object = handle->object;
 	size_t i;
 
@@ -3861,5 +3921,14 @@ const char *llcache_handle_get_header(co
 bool llcache_handle_references_same_object(const llcache_handle *a,
 		const llcache_handle *b)
 {
+	if(a->wh != NULL) {
+		if(b->wh != NULL) {
+			return webfs_handle_references_same_object(a->wh, b->wh);
+		}
+		return false;
+	} else if(b->wh != NULL) {
+		return false;
+	}
+
 	return a->object == b->object;
 }
--- /dev/null	Wed Jan 22 09:00:06 2020
+++ content/webfs.c	Tue Feb  4 17:39:44 2020
@@ -0,0 +1,604 @@
+#include <stdlib.h>
+#include <stdint.h>
+#include <string.h>
+#include <strings.h>
+#include <stdio.h>
+#include <errno.h>
+#include <unistd.h>
+#include <fcntl.h>
+
+
+#include "utils/nsurl.h"
+#include "content/llcache.h"
+#include "netsurf/misc.h"
+#include "desktop/gui_internal.h"
+#include "libwapcaplet/libwapcaplet.h"
+#include "webfs.h"
+
+// TODO: Condense these. There's no reason we need to divide up the work this much.
+typedef enum {
+	DATA_STATE_UNSTARTED,
+	DATA_STATE_CLONED,
+	DATA_STATE_REQUESTED,
+	DATA_STATE_DATA_READY,
+	DATA_STATE_DONE,
+	DATA_STATE_ERROR,
+} data_state;
+
+typedef enum {
+	HANDLE_STATE_START, // Have not sent LLCACHE_EVENT_HAD_HEADERS yet.
+	HANDLE_STATE_DATA,  // In process of sending LLCACHE_EVENT_HAD_DATA.
+	HANDLE_STATE_DONE,  // We are finished. Either by LLCACHE_EVENT_DONE or LLCACHE_EVENT_ERROR.
+} handle_state;
+
+struct webfs_data {
+	data_state state;
+	char *err;
+	char *urls;
+	char *pdat;
+
+	int ctlfd; // fd for /mnt/web/N/ctl
+	int bodyfd; // fd for /mnt/web/N/body
+	char *webdir;
+
+	char *data;
+	int datalen;
+
+	int handle_refcount;
+};
+
+struct webfs_handle {
+	handle_state state;
+	llcache_handle_callback cb;
+	void *pw;
+	bool aborted;
+	int sendindex;
+
+	struct webfs_data *data;
+
+	llcache_handle *handle;
+	
+	struct webfs_handle *prev;
+	struct webfs_handle *next;
+};
+
+struct webfs_handle *handle_head;
+bool scheduled;
+void update_webfs(void *ignored);
+
+void add_node(struct webfs_handle *n) {
+	n->prev = NULL;
+	n->next = handle_head;
+	if(handle_head) {
+		handle_head->prev = n;
+	}
+	handle_head = n;
+	if(!scheduled) {
+		scheduled=true;
+		guit->misc->schedule(10, update_webfs, NULL);
+	}
+}
+
+void remove_node(struct webfs_handle *n) {
+	if(n->prev) {
+		n->prev->next = n->next;
+	}
+	if(n->next) {
+		n->next->prev = n->prev;
+	}
+	if(handle_head == n) {
+		handle_head = n->next;
+	}
+	n->prev = NULL;
+	n->next = NULL;
+}
+
+void webfs_send_data(llcache_handle *handle, webfs_handle *wh) {
+	int tosend = 1024;
+	if(wh->data->datalen - wh->sendindex < tosend) {
+		tosend = wh->data->datalen - wh->sendindex;
+		if(tosend == 0) return;
+	}
+	llcache_event ev;
+	ev.type = LLCACHE_EVENT_HAD_DATA;
+	ev.data.data.buf = (const unsigned char *)wh->data->data + wh->sendindex;
+	ev.data.data.len = tosend;
+	
+	nserror err = wh->cb(handle, &ev, wh->pw);
+	if(err == NSERROR_NEED_DATA) {
+		return;		
+	}
+	else if (err != NSERROR_OK) {
+		// TODO: proper error handling
+		fprintf(stderr, "[DBG]: UNKNOWN ERROR!\n");
+		return;
+	}
+	else {
+		wh->sendindex += tosend;
+	}
+}
+
+/**
+ * Retrieve the post-redirect URL of a low-level cache object
+ *
+ * \param handle  Handle to retrieve URL from
+ * \return Post-redirect URL of cache object
+ */
+nsurl *webfs_handle_get_url(const webfs_handle *wh) {
+	nsurl *url;
+	nserror err = nsurl_create(wh->data->urls, &url);
+	if(err != NSERROR_OK) {
+		return NULL;
+	}
+	return url;
+}
+
+/**
+ * Change the callback associated with a low-level cache handle
+ *
+ * \param handle  Handle to change callback of
+ * \param cb      New callback
+ * \param pw      Client data for new callback
+ * \return NSERROR_OK on success, appropriate error otherwise
+ */
+nserror webfs_handle_change_callback(webfs_handle *wh,
+		llcache_handle_callback cb, void *pw) {
+	wh->cb = cb;
+	wh->pw = pw;
+	return NSERROR_OK;
+}
+
+/**
+ * Abort a low-level fetch, informing all users of this action.
+ *
+ * \param handle  Handle to abort
+ * \return NSERROR_OK on success, appropriate error otherwise
+ */
+nserror webfs_handle_abort(webfs_handle *wh) {
+	wh->aborted = true;
+	return NSERROR_OK;
+}
+
+/**
+ * Retrieve source data of a low-level cache object
+ *
+ * \param handle  Handle to retrieve source data from
+ * \param size    Pointer to location to receive byte length of data
+ * \return Pointer to source data
+ */
+const uint8_t *webfs_handle_get_source_data(const webfs_handle *wh,
+		size_t *size) {
+	*size = wh->data->datalen;
+	return (const uint8_t *)wh->data->data;
+	return NULL;
+}
+
+void webfs_data_release(struct webfs_data *d) {
+	if(d->urls != NULL) {
+		free(d->urls);
+	}
+	if(d->pdat != NULL) {
+		free(d->pdat);
+	}
+	if(d->ctlfd != -1) {
+		close(d->ctlfd);
+		d->ctlfd = -1;
+	}
+	if(d->bodyfd != -1) {
+		close(d->bodyfd);
+		d->bodyfd = -1;
+	}
+	if(d->webdir != NULL) {
+		free(d->webdir);
+	}
+	if(d->data != NULL) {
+		free(d->data);
+	}
+	free(d);
+}
+
+/**
+ * Release a low-level cache handle
+ *
+ * \param handle  Handle to release
+ * \return NSERROR_OK on success, appropriate error otherwise
+ */
+nserror webfs_handle_release(webfs_handle *wh) {
+	wh->aborted=true;
+	wh->data->handle_refcount-=1;
+	if(wh->data->handle_refcount <= 0) {
+		webfs_data_release(wh->data);
+		wh->data = NULL;
+	}
+	remove_node(wh);
+	free(wh);
+	return NSERROR_OK;
+}
+
+/**
+ * Invalidate cache data for a low-level cache object
+ *
+ * \param handle  Handle to invalidate
+ * \return NSERROR_OK on success, appropriate error otherwise
+ */
+nserror webfs_handle_invalidate_cache_data(	) {
+	// TODO
+	return NSERROR_OK;
+}
+
+/**
+ * Clone a low-level cache handle, producing a new handle to
+ * the same fetch/content.
+ *
+ * \param handle  Handle to clone
+ * \param result  Pointer to location to receive cloned handle
+ * \return NSERROR_OK on success, appropriate error otherwise
+ */
+nserror webfs_handle_clone(llcache_handle *handle, webfs_handle *wh, webfs_handle **result) {
+	// TODO (This might be enough already, but revisit and make sure.)
+	webfs_handle *cp = malloc(sizeof (webfs_handle));
+	*cp=*wh;
+	cp->handle = handle;
+	cp->sendindex = 0;
+	cp->state = HANDLE_STATE_START;
+	cp->next = NULL;
+	cp->prev = NULL;
+	*result = cp;
+	add_node(cp);
+	return NSERROR_OK;
+}
+
+char *transform_header_name(char *key) {
+	// TODO I haven't looked at how webfs does this.
+	// this is just a guess. Need to actually do this
+	// right.
+	char *new = malloc(strlen(key));
+	char *newp=new;
+	for(char *c = key; *c != 0; c++) {
+		if((*c >='a' && *c <='z') || (*c >='0' && *c <= '9')){
+			*newp++ = *c;
+		}
+		else if(*c >='A' && *c <= 'Z') {
+			*newp++ = (*c + 32);
+		}
+	}
+	*newp=0;
+	return new;
+}
+
+/**
+ * Retrieve a header value associated with a low-level cache object
+ *
+ * \param handle  Handle to retrieve header from
+ * \param key     Header name
+ * \return Header value, or NULL if header does not exist
+ *
+ * \todo Make the key an enumeration, to avoid needless string comparisons
+ * \todo Forcing the client to parse the header value seems wrong.
+ *       Better would be to return the actual value part and an array of
+ *       key-value pairs for any additional parameters.
+ * \todo Deal with multiple headers of the same key (e.g. Set-Cookie)
+ */
+const char *webfs_handle_get_header(const webfs_handle *wh,
+		const char *key) {
+	// TODO Make this function not terrible.
+	char *newkey = transform_header_name(key);
+	char fname[1024]; // TODO: Again, static? Too big?
+	sprintf(fname, "%s%s", wh->data->webdir, newkey);
+
+	int hfd = open(fname, O_RDONLY);
+	if(hfd < 0) {
+		return NULL;
+	}
+
+	char header_content[4097]; // TODO: Again, really far too big and static.
+	int n = read(hfd, header_content, 4096);
+	header_content[n]=0;
+	char *headerbuf = malloc(n+1);
+	memcpy(headerbuf, header_content, n+1);
+	close(hfd);
+	return headerbuf;
+}
+
+/**
+ * Cause the low-level cache to attempt to perform cleanup.
+ *
+ * No guarantees are made as to whether or not cleanups will take
+ * place and what, if any, space savings will be made.
+ *
+ * \param purge Any objects held in the cache that are safely removable will
+ *              be freed regardless of the configured size limits.
+ */
+void webfs_clean(bool purge) {
+	// TODO
+}
+
+/**
+ * Determine if the same underlying object is referenced by the given handles
+ *
+ * \param a  First handle
+ * \param b  Second handle
+ * \return True if handles reference the same object, false otherwise
+ */
+bool webfs_handle_references_same_object(const webfs_handle *a,
+		const webfs_handle *b) {
+	return a->data == b->data;
+}
+
+/**
+ * Force a low-level cache handle into streaming mode
+ *
+ * \param handle  Handle to stream
+ * \return NSERROR_OK on success, appropriate error otherwise
+ */
+nserror webfs_handle_force_stream(webfs_handle *wh) {
+	// TODO
+	return NSERROR_NOT_IMPLEMENTED;
+}
+
+/**
+ * Initialise the low-level cache
+ *
+ * \param parameters cache configuration parameters.
+ * \return NSERROR_OK on success, appropriate error otherwise.
+ */
+nserror webfs_initialise(const struct llcache_parameters *parameters) {
+	handle_head = NULL;
+	scheduled=false;
+	return NSERROR_OK;
+}
+
+/**
+ * Finalise the low-level cache
+ */
+void webfs_finalise(void) {
+	// TODO
+}
+
+void start_data(struct webfs_data *d) {
+	int ctlfd = open("/mnt/web/clone", O_RDWR);
+	if(ctlfd < 0) {
+		char *e = strerror(errno);
+		fprintf(stderr, "[DBG]: Failed to clone webfs. Error: %s\n", e);
+		d->state = DATA_STATE_ERROR;
+		d->err = "Failed to clone webfs."; // TODO: report strerror?
+		return;
+	}
+	char webd[10]; // 9 digits is plenty.
+	memset(webd, 0, 10);
+	int n = read(ctlfd, webd, 9);
+	webd[n-1]=0;
+
+	d->webdir = malloc(11 + strlen(webd)); // length of "/mnt/web//" + length of webd + NULL
+	n = sprintf(d->webdir, "/mnt/web/%s/", webd);
+	d->state = DATA_STATE_CLONED;
+	d->ctlfd = ctlfd;
+}
+
+void send_request(struct webfs_data *d) {
+
+	if(d->pdat != NULL) {
+		fprintf(stderr, "[DBG]: Setting POST.\n");
+		int n = write(d->ctlfd, "request POST", 12);
+		if(n <= 0) {
+			char *e = strerror(errno);
+			fprintf(stderr, "[DBG]: [%s] Failed to set POST REQUEST. Error: %s\n", d->urls, e);
+			d->state = DATA_STATE_ERROR;
+			d->err = "Failed to clone webfs."; // TODO: report strerror?
+			return;
+		}
+	}
+
+	char urlstr[1024]; // TODO dynamic size?
+	sprintf(urlstr, "url %s", d->urls);
+	int n = write(d->ctlfd, urlstr, strlen(urlstr));
+	if(n <= 0) {
+		char *e = strerror(errno);
+		fprintf(stderr, "[DBG]: [%s] Failed to open URL. Error: %s\n", d->urls, e);
+		d->state = DATA_STATE_ERROR;
+		d->err = "Failed to clone webfs."; // TODO: report strerror?
+		return;
+	}
+
+	d->state = DATA_STATE_REQUESTED;
+}
+
+void start_body(struct webfs_data *d) {
+	char bodystr[1024];
+	sprintf(bodystr, "%sbody", d->webdir);
+	int bodyfd = open(bodystr, O_RDONLY);
+	if(bodyfd < 0) {
+		char *e = strerror(errno);
+		fprintf(stderr, "[DBG]: [%s] Failed to read body. Error: %s\n", d->urls, e);
+		d->state = DATA_STATE_ERROR;
+		d->err = "Failed to clone webfs."; // TODO: report strerror?
+		return;
+	}
+	close(d->ctlfd); //TODO Can we use this?
+	d->ctlfd = -1;
+	d->bodyfd = bodyfd;
+	d->state = DATA_STATE_DATA_READY;
+}
+
+void read_data(struct webfs_data *d) {
+	llcache_event ev;
+	char buf[4097];
+	buf[4096] = 0;
+
+	int n = read(d->bodyfd, buf, 4096);
+	if(n < 0) {
+		char *e = strerror(errno);
+		fprintf(stderr, "[DBG]: [%s] Failed TO READ FROM BODY. Error: %s\n", d->urls, e);
+		d->state = DATA_STATE_ERROR;
+		return;
+	}
+
+	if(n == 0) {
+		d->state = DATA_STATE_DONE;
+		return;
+	}
+
+	if(d->data == NULL) {
+		d->data = malloc(n);
+	} else {
+		d->data = realloc(d->data, d->datalen + n);
+	}
+	memcpy(d->data + d->datalen, buf, n);
+	d->datalen+=n;
+}
+
+void update_data(struct webfs_data *d) {
+	if(d->state == DATA_STATE_ERROR || d->state == DATA_STATE_DONE) {
+		return;
+	}
+	else if(d->state == DATA_STATE_UNSTARTED) {
+		start_data(d);
+	}
+	else if(d->state == DATA_STATE_CLONED) {
+		send_request(d);
+	}
+	else if(d->state == DATA_STATE_REQUESTED) {
+		start_body(d);
+	}
+	else if(d->state = DATA_STATE_DATA_READY) {
+		read_data(d);
+	}
+}
+
+bool llcache_progress(void *h) {
+	struct webfs_handle *wh = h;
+	llcache_handle *handle = wh->handle;
+
+	llcache_event ev;
+
+	// This handle is done. Do nothing.
+	if(wh->state == HANDLE_STATE_DONE || wh->aborted) {
+		return false;
+	}
+
+	// The data has received an error but we haven't reported it
+	// through the handle yet.
+	if(wh->data->state == DATA_STATE_ERROR) {
+		wh->state = HANDLE_STATE_DONE;
+		ev.type = LLCACHE_EVENT_ERROR;
+		ev.data.msg = wh->data->err;
+		wh->cb(handle, &ev, wh->pw);
+		return false;
+	}
+	
+
+	// Make progress on the underlying data.
+	update_data(wh->data);
+
+	// Main if/else chain. Starting with HANDLE_STATE_START
+	if(wh->state == HANDLE_STATE_START) {
+		if (wh->data->state >= DATA_STATE_DATA_READY) {
+			// Data is ready. 
+			ev.type = LLCACHE_EVENT_HAD_HEADERS;
+			wh->cb(handle, &ev, wh->pw);
+			wh->state = HANDLE_STATE_DATA;
+		}
+	}
+	else if(wh->state == HANDLE_STATE_DATA) {
+		// We know data is ready.
+		if(wh->sendindex == wh->data->datalen) {
+			// We're at the end. Check if the data is still coming.
+			if(wh->data->state == DATA_STATE_DONE) {
+				// We sent all the data and no more is coming!
+				ev.type = LLCACHE_EVENT_DONE;
+				wh->cb(handle, &ev, wh->pw);
+				wh->state = HANDLE_STATE_DONE;
+				return true;
+			}
+			// We have no data now, but more is coming.
+			return true;
+		}
+		else {
+			webfs_send_data(handle, wh);
+		}
+	}
+	return true;
+}
+
+void update_webfs(void *ignored) {
+	struct webfs_handle *wh = handle_head;
+	if(wh == NULL) {
+		// Return early to stop scheduling.
+		scheduled=false;
+		return;
+	}
+	while(wh != NULL) {
+		struct webfs_handle *next = wh->next;
+		if(!llcache_progress(wh)) {
+			remove_node(wh);
+		}
+		wh = next;
+	}
+	guit->misc->schedule(10, update_webfs, NULL);
+}
+
+
+/**
+ * Retrieve a handle for a low-level cache object
+ *
+ * \param url      URL of the object to fetch
+ * \param flags    Object retrieval flags
+ * \param referer  Referring URL, or NULL if none
+ * \param post     POST data, or NULL for a GET request
+ * \param cb       Client callback for events
+ * \param pw       Pointer to client-specific data
+ * \param result   Pointer to location to recieve cache handle
+ * \return NSERROR_OK on success, appropriate error otherwise
+ */
+nserror webfs_handle_retrieve(nsurl *url, uint32_t flags,
+		nsurl *referer, const llcache_post_data *post,
+		llcache_handle_callback cb, void *pw, llcache_handle *handle,
+		webfs_handle **result) {
+
+	// We are going to ignore flags for now.
+
+	if(post != NULL) {
+		// TODO Implement POST data.
+		if(post->type == LLCACHE_POST_URL_ENCODED) {
+			fprintf(stderr, "[DBG]: POST DATA: [%s]\n", post->data.urlenc);
+		} else {
+			fprintf(stderr, "[DBG]: POST DATA NOT IMPLEMENTED!\n");
+		}
+		return NSERROR_BAD_CONTENT;
+	}
+
+	char *scheme = lwc_string_data(nsurl_get_component(url, NSURL_SCHEME));
+	if(strcmp("http", scheme) != 0 && strcmp("https", scheme) != 0) {
+		// TODO proper error handling.
+		fprintf(stderr, "[DBG]: Cannot handle the scheme [%s]\n", scheme);
+		abort();
+	}
+
+	webfs_handle *wh = malloc(sizeof *wh);
+	wh->state = HANDLE_STATE_START;
+	wh->cb = cb;
+	wh->pw = pw;
+	wh->aborted = false;
+	wh->sendindex = 0;
+	wh->handle = handle;
+	wh->next = NULL;
+	wh->prev = NULL;
+	wh->data = malloc(sizeof *wh->data);
+	
+	wh->data->state = DATA_STATE_UNSTARTED;
+	char *url_cstr = nsurl_access(url);
+	wh->data->urls = malloc(strlen(url_cstr) + 1);
+	strcpy(wh->data->urls, url_cstr);
+	wh->data->pdat = NULL;
+	wh->data->ctlfd = -1;
+	wh->data->bodyfd = -1;
+	wh->data->webdir = NULL;
+	wh->data->data = NULL;
+	wh->data->datalen = 0;
+	wh->data->handle_refcount = 1;
+	add_node(wh);
+
+	*result = wh;
+
+	return NSERROR_OK;
+}
--- /dev/null	Wed Jan 22 09:00:06 2020
+++ content/webfs.h	Tue Feb  4 17:21:39 2020
@@ -0,0 +1,29 @@
+#ifndef NETSURF_CONTENT_WEBFS_H_
+#define NETSURF_CONTENT_WEBFS_H_
+
+typedef struct webfs_handle webfs_handle;
+
+nsurl *webfs_handle_get_url(const webfs_handle *wh);
+nserror webfs_handle_change_callback(webfs_handle *wh,
+		llcache_handle_callback cb, void *pw);
+nserror webfs_handle_abort(webfs_handle *wh);
+const uint8_t *webfs_handle_get_source_data(const webfs_handle *wh,
+		size_t *size);
+nserror webfs_handle_release(webfs_handle *wh);
+nserror webfs_handle_invalidate_cache_data(webfs_handle *handle);
+nserror webfs_handle_clone(llcache_handle *handle, webfs_handle *wh, webfs_handle **result);
+const char *webfs_handle_get_header(const webfs_handle *wh,
+		const char *key);
+void webfs_clean(bool purge);
+bool webfs_handle_references_same_object(const webfs_handle *a,
+		const webfs_handle *b);
+nserror webfs_handle_force_stream(webfs_handle *wh);
+nserror webfs_initialise(const struct llcache_parameters *parameters);
+void webfs_finalise(void);
+nserror webfs_handle_retrieve(nsurl *url, uint32_t flags,
+		nsurl *referer, const llcache_post_data *post,
+		llcache_handle_callback cb, void *pw, llcache_handle *handle,
+		webfs_handle **result);
+
+
+#endif
--- /mnt/git/branch/heads/plan9/tree/mkfile	Sun Feb  2 19:28:50 2020
+++ mkfile	Tue Feb  4 17:34:21 2020
@@ -40,6 +40,7 @@ OBJ=\
 	content/fetch.$O \
 	content/hlcache.$O \
 	content/llcache.$O \
+	content/webfs.$O \
 	content/mimesniff.$O \
 	content/urldb.$O \
 	content/no_backing_store.$O \

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[kokamoto]

> That works for me. I've not sumbitted patches this way before so correct me if my diffs are not usable.

So, are you going to post the diff here?

Kenji

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

[-- Attachment #1: Type: text/plain, Size: 104 bytes --]

That works for me. I've not sumbitted patches this way before so correct me if my diffs are not usable.

[-- Attachment #2: Type: message/rfc822, Size: 1429 bytes --]

From: ori@eigenstate.org
To: knusbaum@sdf.org, ori@eigenstate.org, 9front@9front.org, echoline@gmail.com
Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)
Date: Tue, 4 Feb 2020 12:11:33 -0800
Message-ID: <067F42E005153D356A4360DC0CB0EC53@eigenstate.org>

> I'm just back. I'll pull your repositories and start trying to integrate my changes. 
> Would you prefer to look at changes through github and pull requests, or is
> there another way everyone prefers to share them?

Personal preference is just diffs on mailing lists, especially
since I'll be applying them from 9front.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

[-- Attachment #1: Type: text/plain, Size: 212 bytes --]

I'm just back. I'll pull your repositories and start trying to integrate my changes. 
Would you prefer to look at changes through github and pull requests, or is
there another way everyone prefers to share them?

[-- Attachment #2: Type: message/rfc822, Size: 1298 bytes --]

From: ori@eigenstate.org
To: knusbaum@sdf.org, 9front@9front.org, echoline@gmail.com
Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)
Date: Mon, 3 Feb 2020 08:00:33 -0800
Message-ID: <7D13682ADB20BC9EADBE417621FC875F@eigenstate.org>

> I am away from home for the next week and didn't bring the code with me.
> 
> I have been hacking on it in my spare time and made some progress. It's not pretty yet, but it's actually minimally useful (to me at least). I will try to get some repos set up on GitHub when I get back if someone wants to look at what I've done.

If you've got something working, I'm very interested to see.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> I'm just back. I'll pull your repositories and start trying to integrate my changes. 
> Would you prefer to look at changes through github and pull requests, or is
> there another way everyone prefers to share them?

Personal preference is just diffs on mailing lists, especially
since I'll be applying them from 9front.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> I am away from home for the next week and didn't bring the code with me.
> 
> I have been hacking on it in my spare time and made some progress. It's not pretty yet, but it's actually minimally useful (to me at least). I will try to get some repos set up on GitHub when I get back if someone wants to look at what I've done.

If you've got something working, I'm very interested to see.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[telephil9]

>>>> 	# get it
>>>> 	git/clone git+ssh://git@github.com/netsurf-plan9/nsport
>>>> 	cd nsport
>>>> 	fetch clone
>>>> 	mk
>>> 
>>> I compiled 5.nsfb, and found it doesn't show the image when I
>>> run 
>>> term%  5.snfb /sys/lib/netsurf/welcome.html.
>>> It shows the ns window, but doesn't the welcome contents.
>> 
>> I fixed a bug that caused this issue on my machine, and just pushed
>> it. Can you go to:
>> 
>> 	nsport/netsurf
>> 
>> and run
>> 
>> 	git/pull
>> 
>> and test again?
>> 
>> Thanks for testing and helping debug!
> 
> Still not working here.
> Status bar shows a "Base stylesheet failed to load" error but nothing gets ever displayed.
> I'm running from the build dir and have run the prepns command from within the netsurf dir.

Ok, looking at the mkfile, I saw there was a 9res target.
Works now after running a 'mk 9res'.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[telephil9]

>>> 	# get it
>>> 	git/clone git+ssh://git@github.com/netsurf-plan9/nsport
>>> 	cd nsport
>>> 	fetch clone
>>> 	mk
>> 
>> I compiled 5.nsfb, and found it doesn't show the image when I
>> run 
>> term%  5.snfb /sys/lib/netsurf/welcome.html.
>> It shows the ns window, but doesn't the welcome contents.
> 
> I fixed a bug that caused this issue on my machine, and just pushed
> it. Can you go to:
> 
> 	nsport/netsurf
> 
> and run
> 
> 	git/pull
> 
> and test again?
> 
> Thanks for testing and helping debug!

Still not working here.
Status bar shows a "Base stylesheet failed to load" error but nothing gets ever displayed.
I'm running from the build dir and have run the prepns command from within the netsurf dir.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kurt H Maier]

On Mon, Feb 03, 2020 at 11:08:05AM +0900, kokamoto@hera.eonet.ne.jp wrote:
> To get my 9front machine's ssh account on github, I have to
> access https://github.com/settings/ssh, and post my
> public key to it.   However, to do it, a javascript enabled
> web browser is neccessary.   Those of abaco or mothra has not.
> 
> If I may not be wrong, I have to cheat github something?
> 
> Kenji
> 


You can also use Github's API to manage ssh keys:
https://developer.github.com/v3/users/keys/

khm

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> To get my 9front machine's ssh account on github, I have to
> access https://github.com/settings/ssh, and post my
> public key to it.   However, to do it, a javascript enabled
> web browser is neccessary.   Those of abaco or mothra has not.


Yes, if you want ssh -- but you can use it anonymously by changing
git+ssh:// to git://. You just won't be able to push changes.

Is there any alternative git hosting that works better, short
of me giving everyone ssh keys to eigenstate.org?

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[kokamoto]

To get my 9front machine's ssh account on github, I have to
access https://github.com/settings/ssh, and post my
public key to it.   However, to do it, a javascript enabled
web browser is neccessary.   Those of abaco or mothra has not.

If I may not be wrong, I have to cheat github something?

Kenji

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

>> 	# get it
>> 	git/clone git+ssh://git@github.com/netsurf-plan9/nsport
>> 	cd nsport
>> 	fetch clone
>> 	mk
> 
> I compiled 5.nsfb, and found it doesn't show the image when I
> run 
> term%  5.snfb /sys/lib/netsurf/welcome.html.
> It shows the ns window, but doesn't the welcome contents.

I fixed a bug that caused this issue on my machine, and just pushed
it. Can you go to:

	nsport/netsurf

and run

	git/pull

and test again?

Thanks for testing and helping debug!

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

It is the same project, just the second is on Github. We (me and Ori) 
are rebasing the changes on top of a cloned stock 3.9 netsurf, so that 
it should be easier to later join/track the upstream netsurf, e.g. 
future development.

Here is a video showing the installation:

https://webbkurs.ei.hv.se/~imjam/plan9/gitinstallnetsurf2.mov

/Jonas

On 2020-02-02 01:46, kokamoto@hera.eonet.ne.jp wrote:

>> # get it
>> git/clone git+ssh://git@github.com/netsurf-plan9/nsport
>> cd nsport
>> fetch clone
>> mk
> 
> I compiled 5.nsfb, and found it doesn't show the image when I
> run
> term%  5.snfb /sys/lib/netsurf/welcome.html.
> It shows the ns window, but doesn't the welcome contents.
> 
> The one by jamos
> https://webbkurs.ei.hv.se/~imjam/plan9/netsurf-3.9-2020-01-24.tgz
> shows them fine.
> 
> These two are different work?
> 
> Kenji

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[kokamoto]

> 	# get it
> 	git/clone git+ssh://git@github.com/netsurf-plan9/nsport
> 	cd nsport
> 	fetch clone
> 	mk

I compiled 5.nsfb, and found it doesn't show the image when I
run 
term%  5.snfb /sys/lib/netsurf/welcome.html.
It shows the ns window, but doesn't the welcome contents.

The one by jamos
https://webbkurs.ei.hv.se/~imjam/plan9/netsurf-3.9-2020-01-24.tgz
shows them fine.

These two are different work?

Kenji

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

>> Since there's a lot of repositories, we've got a repo
>> with management scripts. To get this, assuming you've
>> got a github account set up:
> 
> To setup it on 9front/Plan9 we need to have javascript enbaled web browser,
> where is it?
> 
>> 	# get it
>> 	git/clone git+ssh://git@github.com/netsurf-plan9/nsport

If you don't want to set up an account, just change 'git+ssh' to
'git' in the fetch script.

> I can get git/clone git;//github.com/netsurf-plan9/nsport.git, then
> I got individual git file by:
> git/clone git://github.com/netsurf-plan9/libcss.git etc.
> Then,
>> 	cd nsport
>> 	mk
> 
> Alas! we have no mkfile file in nsport/libwapcaplet/src... etc.

Here, you need to switch to the appropriate branch. The fetch
script does this for you, but since you cloned manually:

	for(m in *)
		@{cd $m && git/branch plan9)

Keep in mind that this is *not* a finished product. Don't
expect sites to load.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[kokamoto]

> Since there's a lot of repositories, we've got a repo
> with management scripts. To get this, assuming you've
> got a github account set up:

To setup it on 9front/Plan9 we need to have javascript enbaled web browser,
where is it?

> 	# get it
> 	git/clone git+ssh://git@github.com/netsurf-plan9/nsport

I can get git/clone git;//github.com/netsurf-plan9/nsport.git, then
I got individual git file by:
git/clone git://github.com/netsurf-plan9/libcss.git etc.
Then,
> 	cd nsport
> 	mk

Alas! we have no mkfile file in nsport/libwapcaplet/src... etc.


Kenji

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Ori Bernstein]

On Sun, 26 Jan 2020 23:10:50 +0200, jamos@oboj.net wrote:

> Hi Eli,
> 
> The new Github repos by Ori are not yet completely up to date with my 
> changes. 

I spent some time on this, and it works for me now:

	https://github.com/netsurf-plan9/

Make sure you update your git9: I fixed a couple of bugs
that this was triggering.

Since there's a lot of repositories, we've got a repo
with management scripts. To get this, assuming you've
got a github account set up:

	# get it
	git/clone git+ssh://git@github.com/netsurf-plan9/nsport
	cd nsport
	fetch clone
	mk

	# use it (local html only so far)
	netsurf/6.nsfb

So, I think it's open season for patches.

-- 
    Ori Bernstein

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

Hi Eli,

The new Github repos by Ori are not yet completely up to date with my 
changes. I am new to Git which makes things slower. For the impatient 
there is still my old tar-ball, updated with a slightly more efficient 
redrawing:

https://webbkurs.ei.hv.se/~imjam/plan9/netsurf-3.9-2020-01-24.tgz

Also, I've compiled a list of changes that I had to make to the source 
in order to make it compile on 9front. People here might have ideas on 
how to solve these issues more elegantly than I do now.

https://webbkurs.ei.hv.se/~imjam/plan9/port_ns39.txt

Now, to your problem. I think you should be able to clone with git:// 
without having any key, and that is how you got the nsport repo.

A learnt that a good way of testing if your ssh-key works properly, is 
to run a 'ssh git@github.com' If it works, it would greet you something 
like:

"Hi <yourgithubname>! You've successfully authenticated, but GitHub does 
not provide shell access."

If it doesn't work you would instead get a message that is very similar 
to the error you describe. Does the key in your factotum work to ssh 
into other Unix machines?

I made my key pair using the instructions in section 8.4.6.3.1 in the 
FQA. Then I uploaded the file 'key.pub' to my Github account, and copied 
the file 'key' (the private key) to my factotum.

/Jonas


On 2020-01-25 17:11, Eli Cohen wrote:

> I'm having all kinds of problems checking this out.
> 
> nsport/fetch clone fails with:
> ssh: auth: no key matches proto=rsa service=ssh role=client
> 
> I have verified there is a key in factotum
> 
> On Fri, Jan 24, 2020 at 10:41 AM <jamos@oboj.net> wrote:
> I just committed the first changes to the git repo that Ori kindly set
> up for the Plan 9 port of Netsurf. I have checked in the files for the
> smallest and simplest library (libwapcaplet) as a test, using git9 by
> Ori. I will continue with the other libraries, and the browser itself.
> Each library is in it's own repo on Github. I'll write again when I
> managed to commit the rest.
> 
> For the curious, you can help me to see if I did everything correctly,
> by checking out and compiling the 'libwapcaplet' library. This is my
> first real Git experience :-)
> 
> git/clone git://github.com/netsurf-plan9/libwapcaplet.git
> 
> Kyle> I have something partially working with webfs
> 
> This is super cool! If you feel for it, it would be interesting to read
> about your efforts and the
> problems you encountered.
> 
> /Jonas
> 
> On 2020-01-24 20:16, Kyle Nusbaum wrote:
> 
> I am away from home for the next week and didn't bring the code with
> me.
> 
> I have been hacking on it in my spare time and made some progress. It's
> not pretty yet, but it's actually minimally useful (to me at least). I
> will try to get some repos set up on GitHub when I get back if someone
> wants to look at what I've done.
> 
> On January 24, 2020 3:09:57 AM EST, Eli Cohen <echoline@gmail.com>
> wrote: bump. did anyone ever put repositories of this up yet? don't let
> them
> shout you down
> 
> On Tue, Jan 7, 2020 at 8:26 PM Kyle Nusbaum <knusbaum@sdf.org> wrote:
> Attachment didn't take. My mistake.
> 
> On January 7, 2020 10:23:40 PM CST, Kyle Nusbaum <knusbaum@sdf.org>
> wrote: I gave up trying talking directly on /net/tcp. It is a pointless
> exercise and would need to be replaced right away anyway.
> 
> I have something partially working with webfs. I replaced the   llcache
> 
> implementation with one that uses webfs. We still need the old
    version

>> to handle objects like "resources:quirks.css" etc.
>> 
>> I'll keep working on it when I get time.
>> I'm attaching a screenshot of the thing partially rendering the
    netsurf

> website.
> 
> On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote: On 2020-01-04
> 19:14, ori@eigenstate.org wrote:
> 
> What I'd do is clone the upstream netsurf repos onto any git host
> that you feel like (except gitlab -- git9 triggers a bug in their
> backend, and I haven't had time to find a workaround), and then
> branch off a 'plan9' branch that we can work on, and commit the
> current state.
> That sounds like a cool way, but I am kind of a git rookie. I
    assume

> that the reason to clone the main repository is that it will be
    easier

> to merge them together eventually? Or even to keep the plan 9
    branch

> up
> to date with new versions of the mainline? I have based my port on
    the

> stable release 3.9 while the core team is happily hacking away on
    what

> even will be the next release (usually one version per year).
> 
> The official site has many git repositories
> (https://source.netsurf-browser.org) - from which I actually downloaded
> every support library separately. Each repository has a tag for
    each

> release. There are also a number of branches (especially for the
    main

> netsurf repository:
> https://source.netsurf-browser.org/netsurf.git/refs/heads) that
    looks

> like experiments.
> 
> I might be inclined to keep it simple to begin with, but if there
    are

> very compelling reasons for a more elaborate way, I might be open
    to

> that, in order to avoid lots of work later on.
> -- Kyle

-- Kyle
-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Eli Cohen]

I'm having all kinds of problems checking this out.

nsport/fetch clone fails with:
ssh: auth: no key matches proto=rsa service=ssh role=client

I have verified there is a key in factotum

On Fri, Jan 24, 2020 at 10:41 AM <jamos@oboj.net> wrote:
>
> I just committed the first changes to the git repo that Ori kindly set
> up for the Plan 9 port of Netsurf. I have checked in the files for the
> smallest and simplest library (libwapcaplet) as a test, using git9 by
> Ori. I will continue with the other libraries, and the browser itself.
> Each library is in it's own repo on Github. I'll write again when I
> managed to commit the rest.
>
> For the curious, you can help me to see if I did everything correctly,
> by checking out and compiling the 'libwapcaplet' library. This is my
> first real Git experience :-)
>
> git/clone git://github.com/netsurf-plan9/libwapcaplet.git
>
> Kyle> I have something partially working with webfs
>
> This is super cool! If you feel for it, it would be interesting to read
> about your efforts and the
> problems you encountered.
>
> /Jonas
>
>
> On 2020-01-24 20:16, Kyle Nusbaum wrote:
>
> > I am away from home for the next week and didn't bring the code with
> > me.
> >
> > I have been hacking on it in my spare time and made some progress. It's
> > not pretty yet, but it's actually minimally useful (to me at least). I
> > will try to get some repos set up on GitHub when I get back if someone
> > wants to look at what I've done.
> >
> > On January 24, 2020 3:09:57 AM EST, Eli Cohen <echoline@gmail.com>
> > wrote: bump. did anyone ever put repositories of this up yet? don't let
> > them
> > shout you down
> >
> > On Tue, Jan 7, 2020 at 8:26 PM Kyle Nusbaum <knusbaum@sdf.org> wrote:
> > Attachment didn't take. My mistake.
> >
> > On January 7, 2020 10:23:40 PM CST, Kyle Nusbaum <knusbaum@sdf.org>
> > wrote: I gave up trying talking directly on /net/tcp. It is a pointless
> > exercise and would need to be replaced right away anyway.
> >
> > I have something partially working with webfs. I replaced the
>   llcache
>
> >> implementation with one that uses webfs. We still need the old
>   version
>
> >> to handle objects like "resources:quirks.css" etc.
> >>
> >> I'll keep working on it when I get time.
> >> I'm attaching a screenshot of the thing partially rendering the
>   netsurf
>
> > website.
> >
> > On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote: On 2020-01-04
> > 19:14, ori@eigenstate.org wrote:
> >
> > What I'd do is clone the upstream netsurf repos onto any git host
> > that you feel like (except gitlab -- git9 triggers a bug in their
> > backend, and I haven't had time to find a workaround), and then
> > branch off a 'plan9' branch that we can work on, and commit the
> > current state.
> > That sounds like a cool way, but I am kind of a git rookie. I
>   assume
>
> > that the reason to clone the main repository is that it will be
>   easier
>
> > to merge them together eventually? Or even to keep the plan 9
>   branch
>
> > up
> > to date with new versions of the mainline? I have based my port on
>   the
>
> > stable release 3.9 while the core team is happily hacking away on
>   what
>
> > even will be the next release (usually one version per year).
> >
> > The official site has many git repositories
> > (https://source.netsurf-browser.org) - from which I actually downloaded
> > every support library separately. Each repository has a tag for
>   each
>
> > release. There are also a number of branches (especially for the
>   main
>
> > netsurf repository:
> > https://source.netsurf-browser.org/netsurf.git/refs/heads) that
>   looks
>
> > like experiments.
> >
> > I might be inclined to keep it simple to begin with, but if there
>   are
>
> > very compelling reasons for a more elaborate way, I might be open
>   to
>
> > that, in order to avoid lots of work later on.
> > -- Kyle
>
> -- Kyle
> -- Kyle



-- 
http://echoline.org

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

I just committed the first changes to the git repo that Ori kindly set 
up for the Plan 9 port of Netsurf. I have checked in the files for the 
smallest and simplest library (libwapcaplet) as a test, using git9 by 
Ori. I will continue with the other libraries, and the browser itself. 
Each library is in it's own repo on Github. I'll write again when I 
managed to commit the rest.

For the curious, you can help me to see if I did everything correctly, 
by checking out and compiling the 'libwapcaplet' library. This is my 
first real Git experience :-)

git/clone git://github.com/netsurf-plan9/libwapcaplet.git

Kyle> I have something partially working with webfs

This is super cool! If you feel for it, it would be interesting to read 
about your efforts and the
problems you encountered.

/Jonas


On 2020-01-24 20:16, Kyle Nusbaum wrote:

> I am away from home for the next week and didn't bring the code with 
> me.
> 
> I have been hacking on it in my spare time and made some progress. It's 
> not pretty yet, but it's actually minimally useful (to me at least). I 
> will try to get some repos set up on GitHub when I get back if someone 
> wants to look at what I've done.
> 
> On January 24, 2020 3:09:57 AM EST, Eli Cohen <echoline@gmail.com> 
> wrote: bump. did anyone ever put repositories of this up yet? don't let 
> them
> shout you down
> 
> On Tue, Jan 7, 2020 at 8:26 PM Kyle Nusbaum <knusbaum@sdf.org> wrote:
> Attachment didn't take. My mistake.
> 
> On January 7, 2020 10:23:40 PM CST, Kyle Nusbaum <knusbaum@sdf.org> 
> wrote: I gave up trying talking directly on /net/tcp. It is a pointless
> exercise and would need to be replaced right away anyway.
> 
> I have something partially working with webfs. I replaced the
  llcache

>> implementation with one that uses webfs. We still need the old
  version

>> to handle objects like "resources:quirks.css" etc.
>> 
>> I'll keep working on it when I get time.
>> I'm attaching a screenshot of the thing partially rendering the
  netsurf

> website.
> 
> On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote: On 2020-01-04 
> 19:14, ori@eigenstate.org wrote:
> 
> What I'd do is clone the upstream netsurf repos onto any git host
> that you feel like (except gitlab -- git9 triggers a bug in their
> backend, and I haven't had time to find a workaround), and then
> branch off a 'plan9' branch that we can work on, and commit the
> current state.
> That sounds like a cool way, but I am kind of a git rookie. I
  assume

> that the reason to clone the main repository is that it will be
  easier

> to merge them together eventually? Or even to keep the plan 9
  branch

> up
> to date with new versions of the mainline? I have based my port on
  the

> stable release 3.9 while the core team is happily hacking away on
  what

> even will be the next release (usually one version per year).
> 
> The official site has many git repositories
> (https://source.netsurf-browser.org) - from which I actually downloaded
> every support library separately. Each repository has a tag for
  each

> release. There are also a number of branches (especially for the
  main

> netsurf repository:
> https://source.netsurf-browser.org/netsurf.git/refs/heads) that
  looks

> like experiments.
> 
> I might be inclined to keep it simple to begin with, but if there
  are

> very compelling reasons for a more elaborate way, I might be open
  to

> that, in order to avoid lots of work later on.
> -- Kyle

-- Kyle
-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

I am away from home for the next week and didn't bring the code with me.

I have been hacking on it in my spare time and made some progress. It's not pretty yet, but it's actually minimally useful (to me at least). I will try to get some repos set up on GitHub when I get back if someone wants to look at what I've done.

On January 24, 2020 3:09:57 AM EST, Eli Cohen <echoline@gmail.com> wrote:
>bump. did anyone ever put repositories of this up yet? don't let them
>shout you down
>
>On Tue, Jan 7, 2020 at 8:26 PM Kyle Nusbaum <knusbaum@sdf.org> wrote:
>>
>> Attachment didn't take. My mistake.
>>
>>
>>
>> On January 7, 2020 10:23:40 PM CST, Kyle Nusbaum <knusbaum@sdf.org>
>wrote:
>> >I gave up trying talking directly on /net/tcp. It is a pointless
>> >exercise and would need to be replaced right away anyway.
>> >
>> >I have something partially working with webfs. I replaced the
>llcache
>> >implementation with one that uses webfs. We still need the old
>version
>> >to handle objects like "resources:quirks.css" etc.
>> >
>> >I'll keep working on it when I get time.
>> >I'm attaching a screenshot of the thing partially rendering the
>netsurf
>> >website.
>> >
>> >
>> >On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote:
>> >>On 2020-01-04 19:14, ori@eigenstate.org wrote:
>> >>
>> >>>
>> >>> What I'd do is clone the upstream netsurf repos onto any git host
>> >>> that you feel like (except gitlab -- git9 triggers a bug in their
>> >>> backend, and I haven't had time to find a workaround), and then
>> >>> branch off a 'plan9' branch that we can work on, and commit the
>> >>> current state.
>> >>
>> >>That sounds like a cool way, but I am kind of a git rookie. I
>assume
>> >>that the reason to clone the main repository is that it will be
>easier
>> >
>> >>to merge them together eventually? Or even to keep the plan 9
>branch
>> >up
>> >>
>> >>to date with new versions of the mainline? I have based my port on
>the
>> >
>> >>stable release 3.9 while the core team is happily hacking away on
>what
>> >
>> >>even will be the next release (usually one version per year).
>> >>
>> >>The official site has many git repositories
>> >>(https://source.netsurf-browser.org) - from which I actually
>> >downloaded
>> >>
>> >>every support library separately. Each repository has a tag for
>each
>> >>release. There are also a number of branches (especially for the
>main
>> >>netsurf repository:
>> >>https://source.netsurf-browser.org/netsurf.git/refs/heads) that
>looks
>> >>like experiments.
>> >>
>> >>I might be inclined to keep it simple to begin with, but if there
>are
>> >>very compelling reasons for a more elaborate way, I might be open
>to
>> >>that, in order to avoid lots of work later on.
>> >
>> >-- Kyle
>>
>> -- Kyle

-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[hiro]

they are busy and have to close some of the tabs first.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Eli Cohen]

bump. did anyone ever put repositories of this up yet? don't let them
shout you down

On Tue, Jan 7, 2020 at 8:26 PM Kyle Nusbaum <knusbaum@sdf.org> wrote:
>
> Attachment didn't take. My mistake.
>
>
>
> On January 7, 2020 10:23:40 PM CST, Kyle Nusbaum <knusbaum@sdf.org> wrote:
> >I gave up trying talking directly on /net/tcp. It is a pointless
> >exercise and would need to be replaced right away anyway.
> >
> >I have something partially working with webfs. I replaced the llcache
> >implementation with one that uses webfs. We still need the old version
> >to handle objects like "resources:quirks.css" etc.
> >
> >I'll keep working on it when I get time.
> >I'm attaching a screenshot of the thing partially rendering the netsurf
> >website.
> >
> >
> >On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote:
> >>On 2020-01-04 19:14, ori@eigenstate.org wrote:
> >>
> >>>
> >>> What I'd do is clone the upstream netsurf repos onto any git host
> >>> that you feel like (except gitlab -- git9 triggers a bug in their
> >>> backend, and I haven't had time to find a workaround), and then
> >>> branch off a 'plan9' branch that we can work on, and commit the
> >>> current state.
> >>
> >>That sounds like a cool way, but I am kind of a git rookie. I assume
> >>that the reason to clone the main repository is that it will be easier
> >
> >>to merge them together eventually? Or even to keep the plan 9 branch
> >up
> >>
> >>to date with new versions of the mainline? I have based my port on the
> >
> >>stable release 3.9 while the core team is happily hacking away on what
> >
> >>even will be the next release (usually one version per year).
> >>
> >>The official site has many git repositories
> >>(https://source.netsurf-browser.org) - from which I actually
> >downloaded
> >>
> >>every support library separately. Each repository has a tag for each
> >>release. There are also a number of branches (especially for the main
> >>netsurf repository:
> >>https://source.netsurf-browser.org/netsurf.git/refs/heads) that looks
> >>like experiments.
> >>
> >>I might be inclined to keep it simple to begin with, but if there are
> >>very compelling reasons for a more elaborate way, I might be open to
> >>that, in order to avoid lots of work later on.
> >
> >-- Kyle
>
> -- Kyle



-- 
http://echoline.org

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]

Attachment didn't take. My mistake.



On January 7, 2020 10:23:40 PM CST, Kyle Nusbaum <knusbaum@sdf.org> wrote:
>I gave up trying talking directly on /net/tcp. It is a pointless
>exercise and would need to be replaced right away anyway. 
>
>I have something partially working with webfs. I replaced the llcache
>implementation with one that uses webfs. We still need the old version
>to handle objects like "resources:quirks.css" etc.
>
>I'll keep working on it when I get time.
>I'm attaching a screenshot of the thing partially rendering the netsurf
>website.
>
>
>On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote:
>>On 2020-01-04 19:14, ori@eigenstate.org wrote:
>>
>>> 
>>> What I'd do is clone the upstream netsurf repos onto any git host
>>> that you feel like (except gitlab -- git9 triggers a bug in their
>>> backend, and I haven't had time to find a workaround), and then
>>> branch off a 'plan9' branch that we can work on, and commit the
>>> current state.
>>
>>That sounds like a cool way, but I am kind of a git rookie. I assume 
>>that the reason to clone the main repository is that it will be easier
>
>>to merge them together eventually? Or even to keep the plan 9 branch
>up
>>
>>to date with new versions of the mainline? I have based my port on the
>
>>stable release 3.9 while the core team is happily hacking away on what
>
>>even will be the next release (usually one version per year).
>>
>>The official site has many git repositories 
>>(https://source.netsurf-browser.org) - from which I actually
>downloaded
>>
>>every support library separately. Each repository has a tag for each 
>>release. There are also a number of branches (especially for the main 
>>netsurf repository: 
>>https://source.netsurf-browser.org/netsurf.git/refs/heads) that looks 
>>like experiments.
>>
>>I might be inclined to keep it simple to begin with, but if there are 
>>very compelling reasons for a more elaborate way, I might be open to 
>>that, in order to avoid lots of work later on.
>
>-- Kyle

-- Kyle

[-- Attachment #2: 85.png --]
[-- Type: image/png, Size: 17754 bytes --]

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

I gave up trying talking directly on /net/tcp. It is a pointless exercise and would need to be replaced right away anyway. 

I have something partially working with webfs. I replaced the llcache implementation with one that uses webfs. We still need the old version to handle objects like "resources:quirks.css" etc.

I'll keep working on it when I get time.
I'm attaching a screenshot of the thing partially rendering the netsurf website.


On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote:
>On 2020-01-04 19:14, ori@eigenstate.org wrote:
>
>> 
>> What I'd do is clone the upstream netsurf repos onto any git host
>> that you feel like (except gitlab -- git9 triggers a bug in their
>> backend, and I haven't had time to find a workaround), and then
>> branch off a 'plan9' branch that we can work on, and commit the
>> current state.
>
>That sounds like a cool way, but I am kind of a git rookie. I assume 
>that the reason to clone the main repository is that it will be easier 
>to merge them together eventually? Or even to keep the plan 9 branch up
>
>to date with new versions of the mainline? I have based my port on the 
>stable release 3.9 while the core team is happily hacking away on what 
>even will be the next release (usually one version per year).
>
>The official site has many git repositories 
>(https://source.netsurf-browser.org) - from which I actually downloaded
>
>every support library separately. Each repository has a tag for each 
>release. There are also a number of branches (especially for the main 
>netsurf repository: 
>https://source.netsurf-browser.org/netsurf.git/refs/heads) that looks 
>like experiments.
>
>I might be inclined to keep it simple to begin with, but if there are 
>very compelling reasons for a more elaborate way, I might be open to 
>that, in order to avoid lots of work later on.

-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

On 2020-01-04 19:14, ori@eigenstate.org wrote:

> 
> What I'd do is clone the upstream netsurf repos onto any git host
> that you feel like (except gitlab -- git9 triggers a bug in their
> backend, and I haven't had time to find a workaround), and then
> branch off a 'plan9' branch that we can work on, and commit the
> current state.

That sounds like a cool way, but I am kind of a git rookie. I assume 
that the reason to clone the main repository is that it will be easier 
to merge them together eventually? Or even to keep the plan 9 branch up 
to date with new versions of the mainline? I have based my port on the 
stable release 3.9 while the core team is happily hacking away on what 
even will be the next release (usually one version per year).

The official site has many git repositories 
(https://source.netsurf-browser.org) - from which I actually downloaded 
every support library separately. Each repository has a tag for each 
release. There are also a number of branches (especially for the main 
netsurf repository: 
https://source.netsurf-browser.org/netsurf.git/refs/heads) that looks 
like experiments.

I might be inclined to keep it simple to begin with, but if there are 
very compelling reasons for a more elaborate way, I might be open to 
that, in order to avoid lots of work later on.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

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

What I'd do is clone the upstream netsurf repos onto any git host
that you feel like (except gitlab -- git9 triggers a bug in their
backend, and I haven't had time to find a workaround), and then
branch off a 'plan9' branch that we can work on, and commit the
current state.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

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

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Steve Simon]

hi,

the response header fields are exposed as psudo-files in webfs, i cannot remember the path just now, but its the per connection directory.

cookies are handled by  webfs when and a file server (cookiejar?) which should “just work”, it should hopefully be just a matter of removing cookie support from netsurf.

it would be exciting to have netsurf running on plan9, especially if the changes where merged back into the mainline.

-Steve




> On 3 Jan 2020, at 8:15 pm, Kyle Nusbaum <knusbaum@sdf.org> wrote:
> 
> A shared repo would be nice. 
> 
> My attempt at using webfs has hit a snag, which is that webfs does not expose the http response header in any way, as far as I can tell. 
> I have it partially working in that it is getting and returning webpage data, but netsurf wants the full response header. 
> 
> I think webfs is not the right solution for this. It is not the general-purpose http service I thought it was. For this purpose, it has several issues. It provides no access to the raw header bytes. We could still use it as a hacky solution if we could reassemble the http header, but webfs mangles header names when creating the header files and leaves out cookies. 
> 
> However, since netsurf seems to do all the parsing of the response except separating header from body, and delivers the request URL and post data in pre-packaged form, I think it's probably easier to just use a raw /net/tcp connection.
> 
> 
> On January 2, 2020 9:30:50 PM CST, ori@eigenstate.org wrote:
>>> Forgive me for any duplicates.  I mistakenly sent a copy of this
>>> mail with HTML.
>>> 
>>> This work is neat!
>>> 
>>> With Ori's changes I see the interface rendered.
>>> 
>>> I think the mouse handling is using absolute coordinates, because
>>> the address bar only works if I position the window in the upper left
>>> corner of my screen.
>>> 
>>> I can't get the program to actually render anything, even file:///
>>> resources, but I can see them getting fetched.
>>> 
>>> I get CSSBase displayed at the bottom of the screen, seeming to
>>> correspond to the NSERROR_CSS_BASE error, but I can't figure out why
>>> that's happening.  I'm guessing that's why nothing is rendered, but
>>> that may be a faulty assumption.
>> 
>> I also haven't seen them render, but I got it to show the ui before
>> I had to run out the door, so I didn't try very hard. 
>> 
>>> The fetcher interface looks pretty straightforward and I think it
>>> shouldn't be too difficult to write a webfs fetcher.  I think I will
>>> try that in my spare time.
>>> 
>> 
>> Cool.
>> 
>> If we're going to have multiple people hacking on this, it
>> probably makes sense to set up a git repository.
>> 
>> It'd be best to use upstream and fork a plan9 branch, so we can
>> merge their changes and start upstreaming our local diffs more
>> easily.
> 
> -- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[hiro]

if you don't want to integrate it properly with 9front, why not stop
porting it to 9front.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

On January 3, 2020 3:01:30 PM CST, ori@eigenstate.org wrote:
>> A shared repo would be nice. 
>> 
>> My attempt at using webfs has hit a snag, which is that webfs
>> does not expose the http response header in any way, as far
>> as I can tell. I have it partially working in that it is
>> getting and returning webpage data, but netsurf wants the
>> full response header. 
>> 
>> I think webfs is not the right solution for this. It is not
>> the general-purpose http service I thought it was. For this
>> purpose, it has several issues. It provides no access to the
>> raw header bytes. We could still use it as a hacky solution
>> if we could reassemble the http header, but webfs mangles
>> header names when creating the header files and leaves out
>> cookies. 
>
>If we want it to handle cookies uniformly, integrate with factotum,
>use devtls, and generally fit into 9front, we definitely want
>to use webfs. It should be sufficiently general purpose for
>our needs.
>
>Is there a reason that tearing out the header parsing code in
>netsurf and pointing it to webfs and webcookies wouldn't work?

I would imagine that should work. However, I haven't dug into the netsurf internals. The fetcher interface seems to be provided for adding ways to pull web pages. Circumventing that is probably necessary for good integration into 9front, but I'm not sure how much work that is. I'll try and see how fetcher is used and see if it can be replaced. I'm not sure what upstream would think of it. Upstream accepting our code is obviously not totally necessary, but it would be nice.

>I'd resist it, but if it's absolutely needed, we can also probably
>add a 'rawheader' file to webfs.

I considered this, but it feels like going the wrong direction. I don't think I want to suggest mucking up our clean interfaces because a port doesn't play nicely with them.

>> However, since netsurf seems to do all the parsing of the
>> response except separating header from body, and delivers
>> the request URL and post data in pre-packaged form, I think
>> it's probably easier to just use a raw /net/tcp connection.
>> 

I think for now I'm going to try and use the fetcher interface with a tcp socket, just to get something working. That might allow us to use http at least and work on other parts of the browser while we look at replacing the fetcher with webfs.
-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> A shared repo would be nice. 
> 
> My attempt at using webfs has hit a snag, which is that webfs
> does not expose the http response header in any way, as far
> as I can tell. I have it partially working in that it is
> getting and returning webpage data, but netsurf wants the
> full response header. 
> 
> I think webfs is not the right solution for this. It is not
> the general-purpose http service I thought it was. For this
> purpose, it has several issues. It provides no access to the
> raw header bytes. We could still use it as a hacky solution
> if we could reassemble the http header, but webfs mangles
> header names when creating the header files and leaves out
> cookies. 

If we want it to handle cookies uniformly, integrate with factotum,
use devtls, and generally fit into 9front, we definitely want
to use webfs. It should be sufficiently general purpose for
our needs.

Is there a reason that tearing out the header parsing code in
netsurf and pointing it to webfs and webcookies wouldn't work?

I'd resist it, but if it's absolutely needed, we can also probably
add a 'rawheader' file to webfs.

> However, since netsurf seems to do all the parsing of the
> response except separating header from body, and delivers
> the request URL and post data in pre-packaged form, I think
> it's probably easier to just use a raw /net/tcp connection.
> 

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

A shared repo would be nice. 

My attempt at using webfs has hit a snag, which is that webfs does not expose the http response header in any way, as far as I can tell. 
I have it partially working in that it is getting and returning webpage data, but netsurf wants the full response header. 

I think webfs is not the right solution for this. It is not the general-purpose http service I thought it was. For this purpose, it has several issues. It provides no access to the raw header bytes. We could still use it as a hacky solution if we could reassemble the http header, but webfs mangles header names when creating the header files and leaves out cookies. 

However, since netsurf seems to do all the parsing of the response except separating header from body, and delivers the request URL and post data in pre-packaged form, I think it's probably easier to just use a raw /net/tcp connection.


On January 2, 2020 9:30:50 PM CST, ori@eigenstate.org wrote:
>> Forgive me for any duplicates.  I mistakenly sent a copy of this
>> mail with HTML.
>> 
>> This work is neat!
>> 
>> With Ori's changes I see the interface rendered.
>> 
>> I think the mouse handling is using absolute coordinates, because
>> the address bar only works if I position the window in the upper left
>> corner of my screen.
>> 
>> I can't get the program to actually render anything, even file:///
>> resources, but I can see them getting fetched.
>> 
>> I get CSSBase displayed at the bottom of the screen, seeming to
>> correspond to the NSERROR_CSS_BASE error, but I can't figure out why
>> that's happening.  I'm guessing that's why nothing is rendered, but
>> that may be a faulty assumption.
>
>I also haven't seen them render, but I got it to show the ui before
>I had to run out the door, so I didn't try very hard. 
>
>> The fetcher interface looks pretty straightforward and I think it
>> shouldn't be too difficult to write a webfs fetcher.  I think I will
>> try that in my spare time.
>> 
>
>Cool.
>
>If we're going to have multiple people hacking on this, it
>probably makes sense to set up a git repository.
>
>It'd be best to use upstream and fork a plan9 branch, so we can
>merge their changes and start upstreaming our local diffs more
>easily.

-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[telephil9]

>>> Hi,
>>> 
>>> For me, it does not even build. I get surprising errors from pcc:
>>> 	??none??: nsglobe.8: opcode out of range 25710
>>> 		probably not a .8 file
>>> 	pcc: 8l: 8l 182088: error
>>> 	mk: pcc -I ../include ...  : exit status=rc 182050: pcc 182059: 8l: 8l 182088: error
>>> 	??none??: nsglobe.8: opcode out of range 25710
>>> 		probably not a .8 file
>>> 	pcc: 8l: 8l 182089: error
>>> 	??none??: nsglobe.8: opcode out of range 25710
>>> 		probably not a .8 file
>>> 	pcc: 8l: 8l 182090: error
>>> 	??none??: nsglobe.8: opcode out of range 25710
>>> 		probably not a .8 file
>>> 	pcc: 8l: 8l 182091: error
>>> 
>>> My 9front install is fairly up to date if that matters.
>>> 
>>> Regards,
>>> Philippe
>> 
>> Forgot to mention the error is in libnsfb tests.
>> When I skip this step, I got the browser building and running.
> 
> Race condition in the mkfile: multiple rules try to output to
> nslglobe.6 when the build is run in parallel, which works poorly.
> 
> Try this version of the mkfile:
> 
> 	</$objtype/mkfile
> 	
> 	CC=pcc
> 	DST=$O.frontend $O.polygon $O.polystar $O.plottest $O.text-speed $O.bitmap $O.path $O.rgb
> 	
> 	HFILES=\
> 		../include/libnsfb.h ../include/libnsfb_cursor.h ../include/libnsfb_event.h \
> 		../include/libnsfb_plot.h ../include/libnsfb_plot_util.h
> 	
> 	
> 	CFLAGS=-I ../include -I . -I ../../posix/include \
> 		-D_POSIX_SOURCE -D_RESEARCH_SOURCE
> 	
> 	LIB=../src/libnsfb.$O.a
> 	
> 	
> 	all:V:	$DST	
> 	
> 	$O.%:	%.$O nsglobe.$O $HFILES $LIB
> 		$CC -o $target $CFLAGS $stem.$O nsglobe.$O $LIB
> 	
> 	%.$O:	$HFILES		# don't combine with following %.$O rules
> 	
> 	%.$O:	%.c
> 		$CC -c $CFLAGS $stem.c
> 	
> 	clean:V:
> 		rm -f $DST frontend.$O polygon.$O polystar.$O plottest.$O text-speed.$O rgb.$O \
> 		bitmap.$O globe.$O nsglobe.$O path.$O
> 
> The mkfiles should really be converted to use a common mk include for these patterns.
> If not /sys/src/cmd/mkmany, then at least ../../ns{lib,many}.

That was it!

Thanks Ori

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[telephil9]

> is the mkfile cast in terms of .8 or .5 object files rather than using .$O ?

No, and even if that was the case I'm building on x86 so using .8 should be ok.

Philippe


> 
> -Steve
> 
> 
>> On 3 Jan 2020, at 10:39 am, telephil9@gmail.com wrote:
>> 
>> 
>> Hi,
>> 
>> For me, it does not even build. I get surprising errors from pcc:
>>    ??none??: nsglobe.8: opcode out of range 25710
>>        probably not a .8 file
>>    pcc: 8l: 8l 182088: error
>>    mk: pcc -I ../include ...  : exit status=rc 182050: pcc 182059: 8l: 8l 182088: error
>>    ??none??: nsglobe.8: opcode out of range 25710
>>        probably not a .8 file
>>    pcc: 8l: 8l 182089: error
>>    ??none??: nsglobe.8: opcode out of range 25710
>>        probably not a .8 file
>>    pcc: 8l: 8l 182090: error
>>    ??none??: nsglobe.8: opcode out of range 25710
>>        probably not a .8 file
>>    pcc: 8l: 8l 182091: error
>> 
>> My 9front install is fairly up to date if that matters.
>> 
>> Regards,
>> Philippe
>> 
>> <mime-attachment>

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

>> Hi,
>> 
>> For me, it does not even build. I get surprising errors from pcc:
>> 	??none??: nsglobe.8: opcode out of range 25710
>> 		probably not a .8 file
>> 	pcc: 8l: 8l 182088: error
>> 	mk: pcc -I ../include ...  : exit status=rc 182050: pcc 182059: 8l: 8l 182088: error
>> 	??none??: nsglobe.8: opcode out of range 25710
>> 		probably not a .8 file
>> 	pcc: 8l: 8l 182089: error
>> 	??none??: nsglobe.8: opcode out of range 25710
>> 		probably not a .8 file
>> 	pcc: 8l: 8l 182090: error
>> 	??none??: nsglobe.8: opcode out of range 25710
>> 		probably not a .8 file
>> 	pcc: 8l: 8l 182091: error
>> 
>> My 9front install is fairly up to date if that matters.
>> 
>> Regards,
>> Philippe
> 
> Forgot to mention the error is in libnsfb tests.
> When I skip this step, I got the browser building and running.

Race condition in the mkfile: multiple rules try to output to
nslglobe.6 when the build is run in parallel, which works poorly.

Try this version of the mkfile:

	</$objtype/mkfile
	
	CC=pcc
	DST=$O.frontend $O.polygon $O.polystar $O.plottest $O.text-speed $O.bitmap $O.path $O.rgb
	
	HFILES=\
		../include/libnsfb.h ../include/libnsfb_cursor.h ../include/libnsfb_event.h \
		../include/libnsfb_plot.h ../include/libnsfb_plot_util.h
	
	
	CFLAGS=-I ../include -I . -I ../../posix/include \
		-D_POSIX_SOURCE -D_RESEARCH_SOURCE
	
	LIB=../src/libnsfb.$O.a
	
	
	all:V:	$DST	
	
	$O.%:	%.$O nsglobe.$O $HFILES $LIB
		$CC -o $target $CFLAGS $stem.$O nsglobe.$O $LIB
	
	%.$O:	$HFILES		# don't combine with following %.$O rules
	
	%.$O:	%.c
		$CC -c $CFLAGS $stem.c
	
	clean:V:
		rm -f $DST frontend.$O polygon.$O polystar.$O plottest.$O text-speed.$O rgb.$O \
		bitmap.$O globe.$O nsglobe.$O path.$O

The mkfiles should really be converted to use a common mk include for these patterns.
If not /sys/src/cmd/mkmany, then at least ../../ns{lib,many}.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Steve Simon]

is the mkfile cast in terms of .8 or .5 object files rather than using .$O ?

-Steve


> On 3 Jan 2020, at 10:39 am, telephil9@gmail.com wrote:
> 
> 
> Hi,
> 
> For me, it does not even build. I get surprising errors from pcc:
>    ??none??: nsglobe.8: opcode out of range 25710
>        probably not a .8 file
>    pcc: 8l: 8l 182088: error
>    mk: pcc -I ../include ...  : exit status=rc 182050: pcc 182059: 8l: 8l 182088: error
>    ??none??: nsglobe.8: opcode out of range 25710
>        probably not a .8 file
>    pcc: 8l: 8l 182089: error
>    ??none??: nsglobe.8: opcode out of range 25710
>        probably not a .8 file
>    pcc: 8l: 8l 182090: error
>    ??none??: nsglobe.8: opcode out of range 25710
>        probably not a .8 file
>    pcc: 8l: 8l 182091: error
> 
> My 9front install is fairly up to date if that matters.
> 
> Regards,
> Philippe
> 
> <mime-attachment>

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[telephil9]

> Hi,
> 
> For me, it does not even build. I get surprising errors from pcc:
> 	??none??: nsglobe.8: opcode out of range 25710
> 		probably not a .8 file
> 	pcc: 8l: 8l 182088: error
> 	mk: pcc -I ../include ...  : exit status=rc 182050: pcc 182059: 8l: 8l 182088: error
> 	??none??: nsglobe.8: opcode out of range 25710
> 		probably not a .8 file
> 	pcc: 8l: 8l 182089: error
> 	??none??: nsglobe.8: opcode out of range 25710
> 		probably not a .8 file
> 	pcc: 8l: 8l 182090: error
> 	??none??: nsglobe.8: opcode out of range 25710
> 		probably not a .8 file
> 	pcc: 8l: 8l 182091: error
> 
> My 9front install is fairly up to date if that matters.
> 
> Regards,
> Philippe

Forgot to mention the error is in libnsfb tests.
When I skip this step, I got the browser building and running.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[telephil9]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

Hi,

For me, it does not even build. I get surprising errors from pcc:
	??none??: nsglobe.8: opcode out of range 25710
		probably not a .8 file
	pcc: 8l: 8l 182088: error
	mk: pcc -I ../include ...  : exit status=rc 182050: pcc 182059: 8l: 8l 182088: error
	??none??: nsglobe.8: opcode out of range 25710
		probably not a .8 file
	pcc: 8l: 8l 182089: error
	??none??: nsglobe.8: opcode out of range 25710
		probably not a .8 file
	pcc: 8l: 8l 182090: error
	??none??: nsglobe.8: opcode out of range 25710
		probably not a .8 file
	pcc: 8l: 8l 182091: error

My 9front install is fairly up to date if that matters.

Regards,
Philippe

[-- Attachment #2: Type: message/rfc822, Size: 5155 bytes --]

From: jamos@oboj.net
To: 9front@9front.org
Subject: [9front] Netsurf 3.9 for Plan 9 (work in progress)
Date: Thu, 02 Jan 2020 00:02:20 +0200
Message-ID: <30b184ac47ef349337078b6caee9c0c4@oboj.net>

Hello everyone,

As some of you know from the 9fans discord channels, I am trying to port 
the web browser Netsurf to Plan9 (9front).
My port is still very much work in progress, but I wanted to publish a 
first version for the ones that might find it interesting to compile and 
run. I started out with the prior work of Jens Staal and AAP that I 
found in different contrib directories, but my port is based on the 
latest stable version.

My port so far uses the 'framebuffer' driver, which means that the 
browser draws in a memory bitmap, than then is copied to a Plan 9 Image 
using loadimage(). It does not work to snarf or paste. If I get good 
success with the framebuffer frontend, I will try to write a native 
frontend for Plan 9 there is already ones for amiga, atari, beos, gtk, 
riscos and windows present.

There is a lot of functionality lacking currently, but it is possible to 
load local web pages, even if they don't display so nicely. There are 
many things to figure out. I have not given fonts any thoughts. It is 
little endian (as I commented out the code that checked for endianess). 
In reality not so much works, but it compiles and something shows... :-) 
There is a lot of README files though, and I am open to all kinds of 
input.

You can the source code here: 
https://webbkurs.ei.hv.se/~imjam/plan9/netsurf-3.9-2020-01-01.tgz

//Jonas Amoson

Ps. Oh, and the port relies heavily on APE-shit, and being a browser it 
also supports a lot of WEB-shit ;-)

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> Forgive me for any duplicates.  I mistakenly sent a copy of this
> mail with HTML.
> 
> This work is neat!
> 
> With Ori's changes I see the interface rendered.
> 
> I think the mouse handling is using absolute coordinates, because
> the address bar only works if I position the window in the upper left
> corner of my screen.
> 
> I can't get the program to actually render anything, even file:///
> resources, but I can see them getting fetched.
> 
> I get CSSBase displayed at the bottom of the screen, seeming to
> correspond to the NSERROR_CSS_BASE error, but I can't figure out why
> that's happening.  I'm guessing that's why nothing is rendered, but
> that may be a faulty assumption.

I also haven't seen them render, but I got it to show the ui before
I had to run out the door, so I didn't try very hard. 

> The fetcher interface looks pretty straightforward and I think it
> shouldn't be too difficult to write a webfs fetcher.  I think I will
> try that in my spare time.
> 

Cool.

If we're going to have multiple people hacking on this, it
probably makes sense to set up a git repository.

It'd be best to use upstream and fork a plan9 branch, so we can
merge their changes and start upstreaming our local diffs more
easily.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

Forgive me for any duplicates. I mistakenly sent a copy of this mail with HTML.

This work is neat!

With Ori's changes I see the interface rendered.

I think the mouse handling is using absolute coordinates, because the address bar only works if I position the window in the upper left corner of my screen.

I can't get the program to actually render anything, even file:/// resources, but I can see them getting fetched.

I get CSSBase displayed at the bottom of the screen, seeming to correspond to the NSERROR_CSS_BASE error, but I can't figure out why that's happening. I'm guessing that's why nothing is rendered, but that may be a faulty assumption.

The fetcher interface looks pretty straightforward and I think it shouldn't be too difficult to write a webfs fetcher. I think I will try that in my spare time.

On January 2, 2020 10:45:47 AM CST, ori@eigenstate.org wrote:
>> On 2020-01-02 00:57, ori@eigenstate.org wrote:
>> 
>>> I get a garbled image (see attached).
>> 
>> This is the most common display, alas.
>> It is possible to tweak a web page in
>> order for it to display slightly more
>> beutifully, that is the file 9html/full.html.
>> 
>> https://webbkurs.ei.hv.se/~imjam/plan9/full_html.png
>> 
>> This is how full.html looks for me.
>> As soon as the bars does not span the whole
>> screen, the picture comes out of sync. As
>> an interesting note, the test programs for
>> the framebuffer driver works as expected
>> (e.g. bitmap/plottest/etc.)
>
>I see the problem:
>
>	loaded = loadimage(drawstate->srvimage, r, drawstate->localimage,
>			drawstate->imagebytes);
>
>The rectangle here is just the portion of the screen that's changed,
>so, eg, a 30x30 icon or something. But drawstate->localimage is the
>full view. So, you're uploading the first bunch of pixels of the image
>instead of the region you want to draw.
>
>Changing the code to create a rectangle representing the whole local
>image and uploading it ungarbles it:
>
>	all.min.x = 0;
>	all.min.y = 0;
>	all.max.x = 800;
>	all.max.y = 600;
>	loaded = loadimage(drawstate->srvimage, all, drawstate->localimage,
>			drawstate->imagebytes);
>
>For efficiency, we would really want a strided load image, but if
>there's
>a native plan 9 gui, that becoems a moot point.
>
>Other comments:
>
>	box->x0, box->y0, box->x1 - box->x0, box->y1 - box->y0
>
>box is just a 'Rectangle', so you can convert once and just pass the
>resulting 'r' around:
>
>	r.min.x = box->x0;
>	r.min.y = box->y0;
>	r.max.x = box->x1;
>	r.max.y = box->y1;
>	update_and_redraw_srvimage(drawstate, r);
>
>>> The garbled image doesn't change with
>>> respect to window size.
>> 
>> Yes, the framebuffer size is set at
>> initialisation, it is set to 800x600.
>> 
>> Jonas

-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> On 2020-01-02 00:57, ori@eigenstate.org wrote:
> 
>> I get a garbled image (see attached).
> 
> This is the most common display, alas.
> It is possible to tweak a web page in
> order for it to display slightly more
> beutifully, that is the file 9html/full.html.
> 
> https://webbkurs.ei.hv.se/~imjam/plan9/full_html.png
> 
> This is how full.html looks for me.
> As soon as the bars does not span the whole
> screen, the picture comes out of sync. As
> an interesting note, the test programs for
> the framebuffer driver works as expected
> (e.g. bitmap/plottest/etc.)

I see the problem:

	loaded = loadimage(drawstate->srvimage, r, drawstate->localimage,
			drawstate->imagebytes);

The rectangle here is just the portion of the screen that's changed,
so, eg, a 30x30 icon or something. But drawstate->localimage is the
full view. So, you're uploading the first bunch of pixels of the image
instead of the region you want to draw.

Changing the code to create a rectangle representing the whole local
image and uploading it ungarbles it:

	all.min.x = 0;
	all.min.y = 0;
	all.max.x = 800;
	all.max.y = 600;
	loaded = loadimage(drawstate->srvimage, all, drawstate->localimage,
			drawstate->imagebytes);

For efficiency, we would really want a strided load image, but if there's
a native plan 9 gui, that becoems a moot point.

Other comments:

	box->x0, box->y0, box->x1 - box->x0, box->y1 - box->y0

box is just a 'Rectangle', so you can convert once and just pass the
resulting 'r' around:

	r.min.x = box->x0;
	r.min.y = box->y0;
	r.max.x = box->x1;
	r.max.y = box->y1;
	update_and_redraw_srvimage(drawstate, r);

>> The garbled image doesn't change with
>> respect to window size.
> 
> Yes, the framebuffer size is set at
> initialisation, it is set to 800x600.
> 
> Jonas

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

On 2020-01-02 00:57, ori@eigenstate.org wrote:

> I get a garbled image (see attached).

This is the most common display, alas.
It is possible to tweak a web page in
order for it to display slightly more
beutifully, that is the file 9html/full.html.

https://webbkurs.ei.hv.se/~imjam/plan9/full_html.png

This is how full.html looks for me.
As soon as the bars does not span the whole
screen, the picture comes out of sync. As
an interesting note, the test programs for
the framebuffer driver works as expected
(e.g. bitmap/plottest/etc.)

> The garbled image doesn't change with
> respect to window size.

Yes, the framebuffer size is set at
initialisation, it is set to 800x600.

Jonas

[-- Attachment #2: full_html.png --]
[-- Type: image/png, Size: 60737 bytes --]

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]

> Hello everyone,
> 
> As some of you know from the 9fans discord channels, I am trying to port 
> the web browser Netsurf to Plan9 (9front).
> My port is still very much work in progress, but I wanted to publish a 
> first version for the ones that might find it interesting to compile and 
> run. I started out with the prior work of Jens Staal and AAP that I 
> found in different contrib directories, but my port is based on the 
> latest stable version.
>
> My port so far uses the 'framebuffer' driver, which means that the 
> browser draws in a memory bitmap, than then is copied to a Plan 9 Image 
> using loadimage(). It does not work to snarf or paste. If I get good 
> success with the framebuffer frontend, I will try to write a native 
> frontend for Plan 9 there is already ones for amiga, atari, beos, gtk, 
> riscos and windows present.

Well, that's definitely progress -- and I'm definitely interested
in enough browser to get me past captive portals and such.

For me, though -- it builds, and it runs, but the image that 
Well, it builds, at least. But when I try to run it, I get a garbled
image (see attached).

The garbled image doesn't change with respect to window size.

 
> There is a lot of functionality lacking currently, but it is possible to 
> load local web pages, even if they don't display so nicely. There are 
> many things to figure out. I have not given fonts any thoughts. It is 
> little endian (as I commented out the code that checked for endianess). 
> In reality not so much works, but it compiles and something shows... :-) 
> There is a lot of README files though, and I am open to all kinds of 
> input.
> 
> You can the source code here: 
> https://webbkurs.ei.hv.se/~imjam/plan9/netsurf-3.9-2020-01-01.tgz
> 
> //Jonas Amoson
> 
> Ps. Oh, and the port relies heavily on APE-shit, and being a browser it 
> also supports a lot of WEB-shit ;-)

[-- Attachment #2: Type: image/png, Size: 8438 bytes --]