From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx.sdf.org ([205.166.94.20]) by ewsd; Thu Jan 2 22:12:14 EST 2020 Received: from [192.168.0.16] (c-98-212-152-230.hsd1.il.comcast.net [98.212.152.230]) (authenticated (0 bits)) by mx.sdf.org (8.15.2/8.14.5) with ESMTPSA id 0033C608003558 (using TLSv1.2 with cipher AES128-GCM-SHA256 (128 bits) verified NO); Fri, 3 Jan 2020 03:12:07 GMT Date: Thu, 02 Jan 2020 21:12:03 -0600 User-Agent: K-9 Mail for Android In-Reply-To: <84247256F02174D48607DE3E6E63F615@eigenstate.org> References: <84247256F02174D48607DE3E6E63F615@eigenstate.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress) To: 9front@9front.org, ori@eigenstate.org, jamos@oboj.net From: Kyle Nusbaum Message-ID: List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: structured ISO-certified rails Forgive me for any duplicates=2E I mistakenly sent a copy of this mail with= HTML=2E This work is neat! With Ori's changes I see the interface rendered=2E I think the mouse handling is using absolute coordinates, because the addr= ess bar only works if I position the window in the upper left corner of my = screen=2E I can't get the program to actually render anything, even file:/// resourc= es, but I can see them getting fetched=2E 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= =2E I'm guessing that's why nothing is rendered, but that may be a faulty a= ssumption=2E The fetcher interface looks pretty straightforward and I think it shouldn'= t be too difficult to write a webfs fetcher=2E I think I will try that in m= y spare time=2E On January 2, 2020 10:45:47 AM CST, ori@eigenstate=2Eorg wrote: >> On 2020-01-02 00:57, ori@eigenstate=2Eorg wrote: >>=20 >>> I get a garbled image (see attached)=2E >>=20 >> This is the most common display, alas=2E >> It is possible to tweak a web page in >> order for it to display slightly more >> beutifully, that is the file 9html/full=2Ehtml=2E >>=20 >> https://webbkurs=2Eei=2Ehv=2Ese/~imjam/plan9/full_html=2Epng >>=20 >> This is how full=2Ehtml looks for me=2E >> As soon as the bars does not span the whole >> screen, the picture comes out of sync=2E As >> an interesting note, the test programs for >> the framebuffer driver works as expected >> (e=2Eg=2E bitmap/plottest/etc=2E) > >I see the problem: > > loaded =3D 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=2E But drawstate->localimage is the >full view=2E So, you're uploading the first bunch of pixels of the image >instead of the region you want to draw=2E > >Changing the code to create a rectangle representing the whole local >image and uploading it ungarbles it: > > all=2Emin=2Ex =3D 0; > all=2Emin=2Ey =3D 0; > all=2Emax=2Ex =3D 800; > all=2Emax=2Ey =3D 600; > loaded =3D 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=2E > >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=2Emin=2Ex =3D box->x0; > r=2Emin=2Ey =3D box->y0; > r=2Emax=2Ex =3D box->x1; > r=2Emax=2Ey =3D box->y1; > update_and_redraw_srvimage(drawstate, r); > >>> The garbled image doesn't change with >>> respect to window size=2E >>=20 >> Yes, the framebuffer size is set at >> initialisation, it is set to 800x600=2E >>=20 >> Jonas -- Kyle