- Dillo-dev - lists.mailman3.com

Good news from fltk!

by Johannes.Hofmann＠gmx.de

On Tue, Apr 08, 2008 at 08:35:44PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote: > > > Jeremy wrote: > > > > There are no regressions that I can see. It feels just as fast and > > > > somewhat less flickery. Mind you, this is a fairly fast machine, it > > > > would be useful if someone with a more low-end box tried it out. > > > > > > I wonder who you could be talking about :) > > > I applied it, but running without double buffering is just not an > > > option for me. Drawing is just very slow no matter what. > > > > Is dillo-fltk useable for you with the patch, but with > > clear_double_buffer() as in current cvs? > > If not, what exactly is the problem? > > Drawing a page of text takes a couple of seconds, as I've always seen with > clear_double_buffer(). Well, I don't expect it to be faster with my patch, but there should be less flicker, so you should be able to start reading while the page is loading. The same effect would I expect from commenting out clear_double_buffer(). Or is the drawing itself faster if you comment out clear_double_buffer()? The point of my patch is to make drawing flicker free as with clear_double_buffer() commented out, but without the memory overhead. What machine do you have? Perhaps I should try to revive an old laptop of mine... > > If that sounds wrong, I'll double-check that I applied it correctly. > I had cut and pasted from the mail, and maybe I missed something. > > > > > Speaking of slow, I wonder whether this menu is usable for the rest of you. > > > http://www.irs.gov/formspubs/lists/0,,id=97817,00.html > > > > Hm, I see something... And I can click on the "Individual", > > "Businesses"... images. > > Is it slow when you scroll around through the items in the menu > of forms at the bottom? It's certainly usable. However you might have noticed that drawing antialiased fonts consumes much more CPU than raster fonts. So you might try fltk2 configured with the --disable-xft option. I actually like good raster fonts better than antialiased ones, but that's a matter of taste. Cheers, Johannes

April 9, 2008

Re: patch: url encode, append input

by jcid＠dillo.org

Hi, On Mon, Apr 07, 2008 at 02:26:14PM +0000, corvid wrote: > a_Url_encode_hex_str() needed to accept a Dstr* because it is not > illegal to use url encoding on a file. Maybe a situation that'll > never happen, but then again, it's easy to leave off enctype. In that case the behaviour is not specified. i.e. (from http://www.ietf.org/rfc/rfc1867.txt) 5.8 File transfer with ENCTYPE=x-www-form-urlencoded If a form contains <INPUT TYPE=file> elements but does not contain an ENCTYPE in the enclosing <FORM>, the behavior is not specified. It is probably inappropriate to attempt to URN-encode large quantities of data to servers that don't expect it. > (However, Firefox -- as if it's any authority on anything, but still -- > doesn't send file contents for URL encoded forms. It just sends > the filename.) Probably is not a bad idea to follow this lead or investigate a bit further on what IE, Safari or Opera do, and then decide. At least, I'd feel more comfortable with a file-size limit for both GET&POST, thus avoiding Dillo to exit because it can't allocate enough memory for sending a huge file. > Html_append_input() becomes a few functions (I'd never felt good > about sending a boundary arg for url encoding anyway). OK. -- Cheers Jorge.-

April 9, 2008

Good news from fltk!

by corvid＠lavabit.com

Johannes wrote: > On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote: > > Jeremy wrote: > > > There are no regressions that I can see. It feels just as fast and > > > somewhat less flickery. Mind you, this is a fairly fast machine, it > > > would be useful if someone with a more low-end box tried it out. > > > > I wonder who you could be talking about :) > > I applied it, but running without double buffering is just not an > > option for me. Drawing is just very slow no matter what. > > Is dillo-fltk useable for you with the patch, but with > clear_double_buffer() as in current cvs? > If not, what exactly is the problem? Drawing a page of text takes a couple of seconds, as I've always seen with clear_double_buffer(). If that sounds wrong, I'll double-check that I applied it correctly. I had cut and pasted from the mail, and maybe I missed something. > > Speaking of slow, I wonder whether this menu is usable for the rest of you. > > http://www.irs.gov/formspubs/lists/0,,id=97817,00.html > > Hm, I see something... And I can click on the "Individual", > "Businesses"... images. Is it slow when you scroll around through the items in the menu of forms at the bottom?

April 9, 2008

Good news from fltk!

by jcid＠dillo.org

Hi, On Tue, Apr 08, 2008 at 08:03:04PM +0200, Johannes Hofmann wrote: > On Tue, Apr 08, 2008 at 05:11:58PM +0100, Jeremy Henty wrote: > > > > On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > > > > > Mostly I would be interested whether it still feels fast. And any > > > regressions you observe, of course... > > > > There are no regressions that I can see. It feels just as fast and > > somewhat less flickery. Mind you, this is a fairly fast machine, it > > would be useful if someone with a more low-end box tried it out. > > Yes we should definately test in on some low-end machines. > Remote X11 is also a good test. I can test it on a slow machine, but next week... > > > BTW, do you think double buffering should be a compile time option - > > > as in the patch? As no special includes are needed we might make it > > > a run time option as well. > > > > I don't know enough about the issues to say. Why would someone want > > to disable double buffering? Resource constraints? An unusual X > > server that doesn't support it very well? > > I can only think of debugging. Without double buffering you see > excessive redraws immediately. The problem we had before the patch in current FLTK, was of memory usage on restrained/embedded systems (one buffer per open window IIRC). Although I'm not sure yet, it'd be good to have it as a dillorc option to make faster comparisons. :-) -- Cheers Jorge.-

April 9, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

On Tue, Apr 08, 2008 at 08:02:05PM +0000, corvid wrote: > Jeremy wrote: > > There are no regressions that I can see. It feels just as fast and > > somewhat less flickery. Mind you, this is a fairly fast machine, it > > would be useful if someone with a more low-end box tried it out. > > I wonder who you could be talking about :) > I applied it, but running without double buffering is just not an > option for me. Drawing is just very slow no matter what. Is dillo-fltk useable for you with the patch, but with clear_double_buffer() as in current cvs? If not, what exactly is the problem? > > Speaking of slow, I wonder whether this menu is usable for the rest of you. > http://www.irs.gov/formspubs/lists/0,,id=97817,00.html Hm, I see something... And I can click on the "Individual", "Businesses"... images. Cheers, Johannes

April 9, 2008

Good news from fltk!

by corvid＠lavabit.com

Jeremy wrote: > There are no regressions that I can see. It feels just as fast and > somewhat less flickery. Mind you, this is a fairly fast machine, it > would be useful if someone with a more low-end box tried it out. I wonder who you could be talking about :) I applied it, but running without double buffering is just not an option for me. Drawing is just very slow no matter what. Speaking of slow, I wonder whether this menu is usable for the rest of you. http://www.irs.gov/formspubs/lists/0,,id=97817,00.html

April 9, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

On Tue, Apr 08, 2008 at 05:11:58PM +0100, Jeremy Henty wrote: > > On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > > > Mostly I would be interested whether it still feels fast. And any > > regressions you observe, of course... > > There are no regressions that I can see. It feels just as fast and > somewhat less flickery. Mind you, this is a fairly fast machine, it > would be useful if someone with a more low-end box tried it out. Yes we should definately test in on some low-end machines. Remote X11 is also a good test. > > > BTW, do you think double buffering should be a compile time option - > > as in the patch? As no special includes are needed we might make it > > a run time option as well. > > I don't know enough about the issues to say. Why would someone want > to disable double buffering? Resource constraints? An unusual X > server that doesn't support it very well? I can only think of debugging. Without double buffering you see excessive redraws immediately. Regards, Johannes

April 8, 2008

Good news from fltk!

by onepoint＠starurchin.org

On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > Mostly I would be interested whether it still feels fast. And any > regressions you observe, of course... There are no regressions that I can see. It feels just as fast and somewhat less flickery. Mind you, this is a fairly fast machine, it would be useful if someone with a more low-end box tried it out. > BTW, do you think double buffering should be a compile time option - > as in the patch? As no special includes are needed we might make it > a run time option as well. I don't know enough about the issues to say. Why would someone want to disable double buffering? Resource constraints? An unusual X server that doesn't support it very well? Regards, Jeremy Henty

April 8, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote: > > On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > > > Attached is a patch that enables double buffering for partial screen > > redraws (this is where the flickering is most annoying). You will > > need at least version r6079 of fltk2 to test. > > OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch > (fixed version). Looks OK so far. Any tests I should run? Mostly I would be interested whether it still feels fast. And any regressions you observe, of course... BTW, do you think double buffering should be a compile time option - as in the patch? As no special includes are needed we might make it a run time option as well. Regards, Johannes

April 8, 2008

Good news from fltk!

by onepoint＠starurchin.org

On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > Attached is a patch that enables double buffering for partial screen > redraws (this is where the flickering is most annoying). You will > need at least version r6079 of fltk2 to test. OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch (fixed version). Looks OK so far. Any tests I should run? Regards, Jeremy Henty

April 8, 2008