April 2008 - Dillo-dev - lists.mailman3.com

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 8, 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 8, 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 8, 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

Re: patch: escape for display

by jcid＠dillo.org

On Sun, Apr 06, 2008 at 11:08:13PM +0000, corvid wrote: > > I ponder having a: > > > > const char *dStr_printable(dStr *in, int maxlen) > > > > that returns a pointer to an internal static dStr. It has > > the advantage of minimal interface overhead. e.g. > > > > - MSG_WARN(" \"%s\"\n", io->Buf->str); > > + MSG_WARN(" \"%s\"\n", dStr_printable(io->Buf, 2048)); > > > > of course it's not MT-safe, but we don't need it now. > > > > Implementing a MT-safe version is easy, but involves more > > calling overhead: > > > > dStr *dStr_printable(dStr *in, int maxlen) > > > > - MSG_WARN(" \"%s\"\n", io->Buf->str); > > + Dstr *printable = dStr_printable(io->Buf, 2048)); > > + MSG_WARN(" \"%s\"\n", printable->str)); > > + dStr_free(printable, 1); > > > > and disabling the message is not as clean as prepending an "_" > > to the macro. > > > > I'd go with the first alternative. > > Attached. > > I wasn't too sure about representation. Text has \x0D where ^M would > be much less surprising, but \x is easier to read for arbitrary bytes. > > It's funny that I had been calling truncation a bug and now I'm > truncating intentionally, but there is only so much a person > wants to see... Committed. -- Cheers Jorge.-

April 7, 2008

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by jcid＠dillo.org

Hi, On Sat, Apr 05, 2008 at 11:58:45AM +0200, Johannes Hofmann wrote: > [...] > I noticed one regression with the new anchor code: > The "Continue Reading Older Posts" link on www.boingboing.net > (e.g. http://www.boingboing.net/2008/04/03/#entry-44240) no longer > scrolls to the right position. I checked with a dillo version even as old as 2007-11-23 and the bug is present. So it's not related to the newest anchor patch. It seems somewhere the offset is not being updated. If I load the page from cache, it works! i.e. file:/tmp/44240.html file:/tmp/44240.html#entry-44240 works OK. Using a cgi to simulate network transfer rate (10KB/sec), I can reproduce the bug: http://localhost/cgi-bin/slow.cgi?10000:/tmp/44240.html#entry-44240 That's what I've found so far. -- Cheers Jorge.-

April 6, 2008

Re: patch: dStr_memmem

by jcid＠dillo.org

Hi, Committed with a minor modification: /* * Return a pointer to the first occurrence of needle in haystack. */ char *dStr_memmem(Dstr *haystack, Dstr *needle) { int i; if (needle && haystack) { if (needle->len == 0) return haystack->str; for (i = 0; i <= (haystack->len - needle->len); i++) { - if (!memcmp(haystack->str + i, needle->str, needle->len)) + if (haystack->str[i] == needle->str[0] && + !memcmp(haystack->str + i, needle->str, needle->len)) return haystack->str + i; } } return NULL; } The idea is to avoid a 3 parameters function call per each checked character. Maybe it's even better to implement it without a function call (like dStristr()), but I haven't done any profiling so I'm not sure. It looks like an improvement though. ;-) -- Cheers Jorge.-

April 6, 2008