- Dillo-dev - lists.mailman3.com

Good news from fltk!

by jcid＠dillo.org

On Tue, Apr 15, 2008 at 09:18:23PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > On Tue, Apr 15, 2008 at 02:38:35PM -0400, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > > > 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... > > > > I found something that looks like a bug in double buffering > > (it doesn't happen with the previous code). > > > > If you: > > > > - ./dillo-fltk about:splash > > - scroll down 1 or 2 inches. > > - browse to another URL. > > - press right mouse button over Back button and return to > > the first page. > > > > You'll end looking to the page through a window artifact in the > > control panel. i.e. The page rendering seems to start from below > > the control PANEL. > > > > Please give it a look. > > Patch 1 should fix the problem. Good! Committed. > > The second patch removes the push_clip() / pop_clip() pair that is no > longer necessary with double buffering (we only copy the needed > rectangle from the backBuffer anyway). > It might result in artifacts when running with > --disable-doublebuffer however. So I'm not sure if you want to > commit that part. I'd commit bracketed as: #ifdef NO_DOUBLEBUFFER push_clip (viewRect); #endif [Drawing code here...] #ifdef NO_DOUBLEBUFFER push_clip (viewRect); #endif Would it be OK? -- Cheers Jorge.-

April 17, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Tue, Apr 15, 2008 at 02:38:35PM -0400, Jorge Arellano Cid wrote: > Hi Johannes, > > On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > > 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... > > I found something that looks like a bug in double buffering > (it doesn't happen with the previous code). > > If you: > > - ./dillo-fltk about:splash > - scroll down 1 or 2 inches. > - browse to another URL. > - press right mouse button over Back button and return to > the first page. > > You'll end looking to the page through a window artifact in the > control panel. i.e. The page rendering seems to start from below > the control PANEL. > > Please give it a look. Patch 1 should fix the problem. The second patch removes the push_clip() / pop_clip() pair that is no longer necessary with double buffering (we only copy the needed rectangle from the backBuffer anyway). It might result in artifacts when running with --disable-doublebuffer however. So I'm not sure if you want to commit that part. Cheers, Johannes

April 15, 2008

Re: patch: BUTTON

by corvid＠lavabit.com

Jorge wrote: > On Tue, Apr 15, 2008 at 04:16:55AM +0000, corvid wrote: > > section 17.2.1 says: > > > > "The elements used to create controls generally appear inside a FORM element, > > but may also appear outside of a FORM element declaration when they are used > > to build user interfaces. This is discussed in the section on intrinsic > > events. [p.254] Note that controls outside a form cannot be successful > > controls [p.245]." > > > > ..but I'll make a separate patch for controls outside of forms. > > AFAICS this may be useful with client side scripts, but we're > a long way from suporting scripts. It's also useful if you want to look at a page that explains tags. The page put up a button tag outside of a form to show me what button tags look like. (plus I've already written the code)

April 15, 2008

Good news from fltk!

by jcid＠dillo.org

Hi Johannes, On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > 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... I found something that looks like a bug in double buffering (it doesn't happen with the previous code). If you: - ./dillo-fltk about:splash - scroll down 1 or 2 inches. - browse to another URL. - press right mouse button over Back button and return to the first page. You'll end looking to the page through a window artifact in the control panel. i.e. The page rendering seems to start from below the control PANEL. Please give it a look. -- Cheers Jorge.-

April 15, 2008

[patch] fix cookies freezing dillo problem

by jcid＠dillo.org

On Fri, Apr 11, 2008 at 11:49:26PM +0200, Andreas Kemnade wrote: > Hi Jorge, > > On Fri, 11 Apr 2008 15:34:49 -0400 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > Note: What still puzzles me, is why accept() returns when > > there's nothing to read. > > > > Hmm, accept() returns when you call connect() on the other side. > Many TCP server programs send stuff to the client before receiving anything > from the client (like ssh servers, smtp servers) so there is nothing unusual > about that. > > So, normally you have > on cookies.dpi side: > accept() > returns after connect() on dillo side > read() > returns after write() on dillo side > > then on dillo side: > read() returns after write() on cookies.dpi side. > > As far as I understand in the race condition case you have: > > dillo cookies.dpi > connect(sock1,...) sock1=accept(....) > connect(sock2,...) (via a_Dpi_send_blocking_cmd) read(sock1,...) > write(sock2,...) (does not block, contents will be added to the recv queue) > read(sock2,...) > > and now, both sides are waiting for data,.... Thanks a lot for the explanation. -- Cheers Jorge.-

April 15, 2008

Re: patch: BUTTON

by jcid＠dillo.org

On Tue, Apr 15, 2008 at 04:16:55AM +0000, corvid wrote: > The old code showed uncertainty about whether one can interact with the > stuff inside a button. The spec doesn't say. I suspect you aren't > supposed to be able to. Firefox doesn't let you. If FF doesn't allow interaction it will be hardly found in the WEB, unless IE allows. :-P > When trying to look up info on button nesting, I discovered -- by crashing -- > that I needed to test whether I was in a form. However, I learned that > section 17.2.1 says: > > "The elements used to create controls generally appear inside a FORM element, > but may also appear outside of a FORM element declaration when they are used > to build user interfaces. This is discussed in the section on intrinsic > events. [p.254] Note that controls outside a form cannot be successful > controls [p.245]." > > ..but I'll make a separate patch for controls outside of forms. AFAICS this may be useful with client side scripts, but we're a long way from suporting scripts. -- Cheers Jorge.-

April 15, 2008

patch: image inputs

by jcid＠dillo.org

On Tue, Apr 15, 2008 at 01:23:47AM +0000, corvid wrote: > Jorge wrote: > > Committed! (with some changes). > > I just noticed that when you took out the other return, > DEBUG_MSG(10, "Html_input_image: unable to create image submit.\n"); > became unconditional. Ooops... Fixed & committed. -- Cheers Jorge.-

April 15, 2008

Re: patch: file input

by jcid＠dillo.org

On Sat, Apr 12, 2008 at 02:06:42AM +0000, corvid wrote: > Jorge wrote: > > On Fri, Apr 11, 2008 at 09:21:16PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote: > > > > > If I read in a file, delete that file, and try to read it in again > > > > > (uses E2EReload), the submit will send the (now empty) file because > > > > > a_Capi_get_buf() finds the (now empty) entry in cache. > > > > > So I'll have to find out where an a_Cache_entry_remove_by_url() should go. > > > > > > > > Yes. > > > > > > It looks like I'd have to figure out CCC for this, which would > > > likely be more trouble than it's worth. > > > > OK, I'll allocate some time to give it a look. > > Cool. Patch committed. After pondering whether to add a URL flag to discriminate a file-input loaded-file (to be able to free it later), the complexities of it being also used/displayed by another Dillo window (and the inherent races), and the necessary handling code, I preferred a local load. The async approach may be done, but the committed approach is simpler, gets the work done, and may be extended to handle multiple files. I also added a handy heuristic for content-type detection of files (it works well with the w3c validator). -- Cheers Jorge.-

April 15, 2008

patch: image inputs

by corvid＠lavabit.com

Jorge wrote: > Committed! (with some changes). I just noticed that when you took out the other return, DEBUG_MSG(10, "Html_input_image: unable to create image submit.\n"); became unconditional.

April 15, 2008

patch: image inputs

by jcid＠dillo.org

On Mon, Apr 14, 2008 at 09:30:17PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Apr 14, 2008 at 05:22:44AM +0000, corvid wrote: > > > > > Committed! (with some changes). > > Wow. I expected to have to go through a few iterations... > > > > - If the image could not be loaded and you click on the alt text, the click > > > position is sent, even though it's not meaningful. > > > > Is there a standard/suggested behaviour in this case? > > All the spec said was: > "When a pointing device is used to click on the image, the form is submitted > and the click coordinates passed to the server. The x value is measured in > pixels [p.52] from the left of the image, and the y value in pixels [p.52]r > from the top of the image. The submitted data includes name.x=x-value and > name.y=y-value where "name" is the value of the name attribute, and x-value > and y-value are the x and y coordinate values, respectively." > > Let's see what our friend Firefox does: > - it _never_ sends name=value. > - for alt text, you get name.x=&name.y= > - if you tab to an image and press enter to submit, you get name.x=0&name.y=0 > - If you click on an image, you get name.x=n&name.y=m OK, so it looks like nobody uses it, in the not-in-minimal multibrowser set. Well, at least it will serve as a warm up for image maps! :-) -- Cheers Jorge.-

April 15, 2008

patch: image inputs

by corvid＠lavabit.com

Jorge wrote: > On Mon, Apr 14, 2008 at 05:22:44AM +0000, corvid wrote: > > > Committed! (with some changes). Wow. I expected to have to go through a few iterations... > > - If the image could not be loaded and you click on the alt text, the click > > position is sent, even though it's not meaningful. > > Is there a standard/suggested behaviour in this case? All the spec said was: "When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels [p.52] from the left of the image, and the y value in pixels [p.52]r from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where "name" is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively." Let's see what our friend Firefox does: - it _never_ sends name=value. - for alt text, you get name.x=&name.y= - if you tab to an image and press enter to submit, you get name.x=0&name.y=0 - If you click on an image, you get name.x=n&name.y=m

April 14, 2008

[patch] fix warning in html.cc

by jcid＠dillo.org

On Mon, Apr 14, 2008 at 05:20:41PM +0200, Johannes Hofmann wrote: > Hi, > > html.cc: In function 'void a_Html_form_event_handler(void*, form::Form*, void*)': > html.cc:4331: warning: 'input' may be used uninitialized in this function > > can be fixed with attached patch. Please review. It looks OK. Committed. -- Cheers Jorge.-

April 14, 2008

patch: image inputs

by jcid＠dillo.org

Hi, On Mon, Apr 14, 2008 at 05:22:44AM +0000, corvid wrote: > It works on the sites I tried, and the data sent looks right for other cases, Committed! (with some changes). > but: > > - To get click position, I used event_x() and event_y() in fltkui.cc because > they happened to have the right values in them and I didn't know the proper > place to look for this information. AFAIU (which is not that much in dw2 ;), it looks OK. > - If the image could not be loaded and you click on the alt text, the click > position is sent, even though it's not meaningful. Is there a standard/suggested behaviour in this case? > - I don't prevent the image from being loaded even when automatic image > loading is disabled (but I'm the only person who would notice anyway). No. "Img off" is a very useful option! Now, that traffic shapers degrade bandwidth, and that sometimes wireless is slow, not to mention dialups, it's quite handy. > (I would have to be able to get button 3 to bring up the image menu.) Could be. -- Cheers Jorge.-

April 14, 2008

[patch] fix warning in html.cc

by corvid＠lavabit.com

Johannes wrote: > html.cc: In function 'void a_Html_form_event_handler(void*, form::Form*, void*)': > html.cc:4331: warning: 'input' may be used uninitialized in this function Oops. I thought it was strange that I hadn't gotten this warning, and now I learn that one does not get -Wuninitialized if -O is turned off. I've been compiling without -O to make debugging easy.

April 14, 2008

[patch] fix warning in html.cc

by Johannes.Hofmann＠gmx.de

Hi, html.cc: In function 'void a_Html_form_event_handler(void*, form::Form*, void*)': html.cc:4331: warning: 'input' may be used uninitialized in this function can be fixed with attached patch. Please review. Cheers, Johannes

April 14, 2008

patch: image inputs

by corvid＠lavabit.com

It works on the sites I tried, and the data sent looks right for other cases, but: - To get click position, I used event_x() and event_y() in fltkui.cc because they happened to have the right values in them and I didn't know the proper place to look for this information. - If the image could not be loaded and you click on the alt text, the click position is sent, even though it's not meaningful. - I don't prevent the image from being loaded even when automatic image loading is disabled (but I'm the only person who would notice anyway). (I would have to be able to get button 3 to bring up the image menu.)

April 14, 2008

[patch] make ComplexButton work

by jcid＠dillo.org

On Sun, Apr 13, 2008 at 09:24:35PM +0200, Johannes Hofmann wrote: > Hi, > > this patch fixes ComplexButton - at least it works here now :-) > The patch includes the ComplexButton destructor proposed by place > and enables the ComplexButton code in dw-ui-test. > It requires my last FltkViewBase::draw() patch. OK. Committed both. -- Cheers Jorge.-

April 14, 2008

[patch] cleanup FltkViewBase::draw

by jcid＠dillo.org

On Sun, Apr 13, 2008 at 09:05:35PM +0200, Johannes Hofmann wrote: > Hi, > > here comes a cleanup of FltkViewBase::draw(). It had grown too > complicated... > This patch also fixes two issues with nested views as they will > exist with ComplexButtons. Committed. -- Cheers Jorge.-

April 13, 2008

[patch] make ComplexButton work

by corvid＠lavabit.com

Johannes wrote: > this patch fixes ComplexButton - at least it works here now :-) It's working for me, too! :)

April 13, 2008

[patch] make ComplexButton work

by Johannes.Hofmann＠gmx.de

Hi, this patch fixes ComplexButton - at least it works here now :-) The patch includes the ComplexButton destructor proposed by place and enables the ComplexButton code in dw-ui-test. It requires my last FltkViewBase::draw() patch. Cheers, Johannes

April 13, 2008

[patch] cleanup FltkViewBase::draw

by Johannes.Hofmann＠gmx.de

Hi, here comes a cleanup of FltkViewBase::draw(). It had grown too complicated... This patch also fixes two issues with nested views as they will exist with ComplexButtons. Cheers, Johannes

April 13, 2008

Re: patch: reset input

by jcid＠dillo.org

Hi, Committed -- Cheers Jorge.-

April 13, 2008

Re: patch: ISINDEX

by jcid＠dillo.org

On Sun, Apr 13, 2008 at 02:33:00AM +0000, corvid wrote: > Yeah, so very important... > > An isindex page: http://www.math.ncu.edu.tw/~shann/bcc16/7/html/isindex.cgi > Committed! Mmmm, ISINDEX, an old method that brings me back good memories. -- Cheers Jorge.-

April 13, 2008

Re: patch: file input

by corvid＠lavabit.com

Jorge wrote: > On Fri, Apr 11, 2008 at 09:21:16PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote: > > > > If I read in a file, delete that file, and try to read it in again > > > > (uses E2EReload), the submit will send the (now empty) file because > > > > a_Capi_get_buf() finds the (now empty) entry in cache. > > > > So I'll have to find out where an a_Cache_entry_remove_by_url() should go. > > > > > > Yes. > > > > It looks like I'd have to figure out CCC for this, which would > > likely be more trouble than it's worth. > > OK, I'll allocate some time to give it a look. Cool. Sort of on topic, what do you think of reviving use of the bug tracker for the various little things that are easy to forget about?

April 12, 2008

Re: patch: file input

by jcid＠dillo.org

On Fri, Apr 11, 2008 at 09:21:16PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote: > > > If I read in a file, delete that file, and try to read it in again > > > (uses E2EReload), the submit will send the (now empty) file because > > > a_Capi_get_buf() finds the (now empty) entry in cache. > > > So I'll have to find out where an a_Cache_entry_remove_by_url() should go. > > > > Yes. > > It looks like I'd have to figure out CCC for this, which would > likely be more trouble than it's worth. OK, I'll allocate some time to give it a look. -- Cheers Jorge.-

April 12, 2008

[patch] fix cookies freezing dillo problem

by akemnade＠tzi.de

Hi Jorge, On Fri, 11 Apr 2008 15:34:49 -0400 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Note: What still puzzles me, is why accept() returns when > there's nothing to read. > Hmm, accept() returns when you call connect() on the other side. Many TCP server programs send stuff to the client before receiving anything from the client (like ssh servers, smtp servers) so there is nothing unusual about that. So, normally you have on cookies.dpi side: accept() returns after connect() on dillo side read() returns after write() on dillo side then on dillo side: read() returns after write() on cookies.dpi side. As far as I understand in the race condition case you have: dillo cookies.dpi connect(sock1,...) sock1=accept(....) connect(sock2,...) (via a_Dpi_send_blocking_cmd) read(sock1,...) write(sock2,...) (does not block, contents will be added to the recv queue) read(sock2,...) and now, both sides are waiting for data,.... Greetings Andreas Kemnade

April 12, 2008

Re: patch: file input

by corvid＠lavabit.com

Jorge wrote: > On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote: > > If I read in a file, delete that file, and try to read it in again > > (uses E2EReload), the submit will send the (now empty) file because > > a_Capi_get_buf() finds the (now empty) entry in cache. > > So I'll have to find out where an a_Cache_entry_remove_by_url() should go. > > Yes. It looks like I'd have to figure out CCC for this, which would likely be more trouble than it's worth.

April 11, 2008

Re: patch: file input

by jcid＠dillo.org

On Fri, Apr 11, 2008 at 07:12:06PM +0000, corvid wrote: > Jorge wrote: > > On Fri, Apr 11, 2008 at 05:48:25PM +0000, corvid wrote: > > > BTW, do you think dillo should do anything if it gets a huge file from > > > a server but didn't know to expect the file to be huge ahead of time > > > (no content length, or chunked transfer encoding)? > > > > Yes, of course. > > I mean should it take some particular action (a dialog or something) > once it figures out that it's N megs into something big? Good question. ;) Considering that we can only flag the entry as HUGE after it has grown a lot, aborting the connection and removing the entry is not an option. For root URLs: stopping the transfer could be offered, but OTOH the user can press the "Stop" button at will, and if he hasn't, we can assume he wants to continue (i.e. leave dillo2 "as is"). For non root URLs (mainly images): stopping the transfer once the threshold has being met, could be. Especially if we consider that the pixmap size is much bigger than the data, it makes sense. If it's simple to implement, it may be worth the effort. BTW, if we have a user clicking an iso, or movie that's served as "text/plain", the internal content-type checker will catch it, abort the connection, and leave the option of "Save link as...". -- Cheers Jorge.-

April 11, 2008

[patch] fix cookies freezing dillo problem

by jcid＠dillo.org

Hi Andreas, On Fri, Apr 11, 2008 at 07:42:29PM +0200, Andreas Kemnade wrote: > Hi, > > after some debugging I found out > that dillo was frozen because it waits for input on the unix > socket from the cookies.dpi. > cookies.dpi itself blocks on the read() on the connection socket. > > If you kill dillo and stop dpid, the next time > the cookies.dpi starts, it finds the cookies files locked and terminates > immedediately. Then dpid starts the cookies.dpi again and again in an > infinite loop. > > In my theory, the freeze where both processes are hanging in read() > is caused when a connection is creating via > DEBUG_MSG(5, "Cookies.c: a_Cookies_set \n\t \"%s\" \n",cmd ); > a_Capi_dpi_send_cmd(NULL, NULL, cmd, "cookies", 1); > > but the data is not send yet and > /* Get the answer from cookies.dpi */ > dpip_tag = a_Dpi_send_blocking_cmd("cookies", cmd); > is called. > > I have attached a patch which uses a_Dpi_send_blocking_cmd(). > It seems to fix the problem. dillo has not been frozen again yet. > Maybe cookies.dpi should create the SockHandler only when there > is data to read (checking for it with select() first). I have the same patch here! (with a few minor additions). What was really misleading for me, was that the old dillo-0.8.6 has no problem at all with using the non-blocking: a_Capi_dpi_send_cmd(NULL, NULL, cmd, "cookies", 1); So AFAIS it ended being a race-condition problem. This is, the cookie_set command was requested before the cookie_get for the next image, but were answered in the reverse order in dillo2 but not in dillo1! Note: What still puzzles me, is why accept() returns when there's nothing to read. I'll commit to let it have more testing. Thanks for the help. > Index: src/cookies.c > =================================================================== > RCS file: /sfhome/cvs/dillo/dillo2/src/cookies.c,v > retrieving revision 1.4 > diff -u -r1.4 cookies.c > --- src/cookies.c 24 Feb 2008 22:15:53 -0000 1.4 > +++ src/cookies.c 11 Apr 2008 17:41:48 -0000 > @@ -155,6 +155,7 @@ > } > > for (i = 0; (cookie_string = dList_nth_data(cookie_strings, i)); ++i) { > + char *dpip_tag; > path = URL_PATH_(set_url); > snprintf(numstr, 16, "%d", URL_PORT(set_url)); > cmd = a_Dpip_build_cmd("cmd=%s cookie=%s host=%s path=%s port=%s", > @@ -162,7 +163,10 @@ > path ? path : "/", numstr); > > DEBUG_MSG(5, "Cookies.c: a_Cookies_set \n\t \"%s\" \n",cmd ); > - a_Capi_dpi_send_cmd(NULL, NULL, cmd, "cookies", 1); > + dpip_tag = a_Dpi_send_blocking_cmd("cookies", cmd); > + if (dpip_tag != NULL) { > + dFree(dpip_tag); > + } > dFree(cmd); > } > } -- Cheers Jorge.-

April 11, 2008

Re: patch: file input

by corvid＠lavabit.com

Jorge wrote: > On Fri, Apr 11, 2008 at 05:48:25PM +0000, corvid wrote: > > BTW, do you think dillo should do anything if it gets a huge file from > > a server but didn't know to expect the file to be huge ahead of time > > (no content length, or chunked transfer encoding)? > > Yes, of course. I mean should it take some particular action (a dialog or something) once it figures out that it's N megs into something big?

April 11, 2008

Re: patch: file input

by jcid＠dillo.org

On Fri, Apr 11, 2008 at 05:48:25PM +0000, corvid wrote: > Jorge wrote: > > On Fri, Apr 11, 2008 at 02:33:50PM +0000, corvid wrote: > > > Jorge wrote: > > > > Please also add a file size threshold, to avoid a dillo exit from an > > > > out of memory condition. > > > > > > Does something like this sound about right? > > > > Yes, but I'd add a WEB_RootUrl check: > > > > + if (entry->Flags & CA_HugeFile) { > > + AbortEntry = TRUE; > > + a_UIcmd_set_msg(Client_bw,"Huge file! (%dMB)", > > + entry->ExpectedSize / (1024*1024)); > > ++ if (ClientWeb->flags & WEB_RootUrl && > > + dStrcasecmp(URL_SCHEME(entry->Url), "file")) > > + OfferDownload = TRUE; > > + } > > I saw that the current code only did so for root URLs, but I didn't > realize it was intentional. It may look a bit strange, but a download offer on a URL the user didn't request directly may be puzzling. > BTW, do you think dillo should do anything if it gets a huge file from > a server but didn't know to expect the file to be huge ahead of time > (no content length, or chunked transfer encoding)? Yes, of course. -- Cheers Jorge.-

April 11, 2008

Re: patch: file input

by corvid＠lavabit.com

Jorge wrote: > On Fri, Apr 11, 2008 at 02:33:50PM +0000, corvid wrote: > > Jorge wrote: > > > Please also add a file size threshold, to avoid a dillo exit from an > > > out of memory condition. > > > > Does something like this sound about right? > > Yes, but I'd add a WEB_RootUrl check: > > + if (entry->Flags & CA_HugeFile) { > + AbortEntry = TRUE; > + a_UIcmd_set_msg(Client_bw,"Huge file! (%dMB)", > + entry->ExpectedSize / (1024*1024)); > ++ if (ClientWeb->flags & WEB_RootUrl && > + dStrcasecmp(URL_SCHEME(entry->Url), "file")) > + OfferDownload = TRUE; > + } I saw that the current code only did so for root URLs, but I didn't realize it was intentional. BTW, do you think dillo should do anything if it gets a huge file from a server but didn't know to expect the file to be huge ahead of time (no content length, or chunked transfer encoding)?

April 11, 2008

[patch] fix cookies freezing dillo problem

by akemnade＠tzi.de

Hi, after some debugging I found out that dillo was frozen because it waits for input on the unix socket from the cookies.dpi. cookies.dpi itself blocks on the read() on the connection socket. If you kill dillo and stop dpid, the next time the cookies.dpi starts, it finds the cookies files locked and terminates immedediately. Then dpid starts the cookies.dpi again and again in an infinite loop. In my theory, the freeze where both processes are hanging in read() is caused when a connection is creating via DEBUG_MSG(5, "Cookies.c: a_Cookies_set \n\t \"%s\" \n",cmd ); a_Capi_dpi_send_cmd(NULL, NULL, cmd, "cookies", 1); but the data is not send yet and /* Get the answer from cookies.dpi */ dpip_tag = a_Dpi_send_blocking_cmd("cookies", cmd); is called. I have attached a patch which uses a_Dpi_send_blocking_cmd(). It seems to fix the problem. dillo has not been frozen again yet. Maybe cookies.dpi should create the SockHandler only when there is data to read (checking for it with select() first). Greetings Andreas Kemnade

April 11, 2008

Re: patch: file input

by jcid＠dillo.org

On Fri, Apr 11, 2008 at 02:33:50PM +0000, corvid wrote: > Jorge wrote: > > Please also add a file size threshold, to avoid a dillo exit from an > > out of memory condition. > > Does something like this sound about right? Yes, but I'd add a WEB_RootUrl check: + if (entry->Flags & CA_HugeFile) { + AbortEntry = TRUE; + a_UIcmd_set_msg(Client_bw,"Huge file! (%dMB)", + entry->ExpectedSize / (1024*1024)); ++ if (ClientWeb->flags & WEB_RootUrl && + dStrcasecmp(URL_SCHEME(entry->Url), "file")) + OfferDownload = TRUE; + } > diff -pur dillo2/src/cache.c dillo2-cur/src/cache.c > --- dillo2/src/cache.c 2008-03-29 15:14:11.000000000 +0000 > +++ dillo2-cur/src/cache.c 2008-04-11 14:25:55.000000000 +0000 > @@ -861,16 +861,18 @@ static void Cache_process_queue(CacheEnt > } else { > Client_bw->redirect_level = 0; > } > - if (entry->Flags & CA_HugeFile) { > - a_UIcmd_set_msg(Client_bw,"Huge file! (%dMB)", > - entry->ExpectedSize / (1024*1024)); > - AbortEntry = OfferDownload = TRUE; > - } > } else { > /* For non root URLs, ignore redirections and 404 answers */ > if (entry->Flags & CA_Redirect || entry->Flags & CA_NotFound) > Client->Callback = Cache_null_client; > } > + if (entry->Flags & CA_HugeFile) { > + AbortEntry = TRUE; > + a_UIcmd_set_msg(Client_bw,"Huge file! (%dMB)", > + entry->ExpectedSize / (1024*1024)); > + if (dStrcasecmp(URL_SCHEME(entry->Url), "file")) > + OfferDownload = TRUE; > + } > > /* Set the client function */ > if (!Client->Callback) { > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- Cheers Jorge.-

April 11, 2008

Re: patch: file input

by corvid＠lavabit.com

Jorge wrote: > Please also add a file size threshold, to avoid a dillo exit from an > out of memory condition. Does something like this sound about right?

April 11, 2008

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by Johannes.Hofmann＠gmx.de

On Fri, Apr 11, 2008 at 10:02:55AM -0400, Jorge Arellano Cid wrote: > On Fri, Apr 11, 2008 at 02:50:03PM +0200, Johannes Hofmann wrote: > > On Thu, Apr 10, 2008 at 06:08:43PM -0400, Jorge Arellano Cid wrote: > > > Hi, > > > > > > I just committed the implementation of a_Dialog_choice5(). This > > > function allows for question dialogs with max. 5 options. It is > > > used by https, and you can test it with "dpi:/hello/". > > > > > > As stated above, dpi programs can ask questions by sending a > > > dpi command and receiving an answer from dillo. > > > > > > This implementation is modal, but if there's a need to make it > > > non-modal, it should be easy to implement choice5 as a class with > > > internal state and to issue the callback from there. > > > > > > Please excuse the late patch, but I had a lot to review and I > > > still can't trap the freeze on: > > > > > > http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 > > > > > > (with cookies enabled.) :-P > > > > I'm not too worried about that. First, there is still developers > > focused on fltk2. Second, if eventually fltk-1.3 (or whatever it > > will be called) should turn out to be better supported, more stable, > > or have important features I think we can port dillo-fltk over within > > one or two weeks. > > Funny how my sentence had at least two reads! :-) > > I agree with you, but what I was trying to say is that dillo2 > freezes (i.e. gets into a non-resposive state) if you have cookies > enabled for www.fltk.org and you start it with that URL. :-) Ahh, that freeze you mean :-) Cheers, Johannes

April 11, 2008

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by jcid＠dillo.org

On Fri, Apr 11, 2008 at 02:50:03PM +0200, Johannes Hofmann wrote: > On Thu, Apr 10, 2008 at 06:08:43PM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > I just committed the implementation of a_Dialog_choice5(). This > > function allows for question dialogs with max. 5 options. It is > > used by https, and you can test it with "dpi:/hello/". > > > > As stated above, dpi programs can ask questions by sending a > > dpi command and receiving an answer from dillo. > > > > This implementation is modal, but if there's a need to make it > > non-modal, it should be easy to implement choice5 as a class with > > internal state and to issue the callback from there. > > > > Please excuse the late patch, but I had a lot to review and I > > still can't trap the freeze on: > > > > http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 > > > > (with cookies enabled.) :-P > > I'm not too worried about that. First, there is still developers > focused on fltk2. Second, if eventually fltk-1.3 (or whatever it > will be called) should turn out to be better supported, more stable, > or have important features I think we can port dillo-fltk over within > one or two weeks. Funny how my sentence had at least two reads! :-) I agree with you, but what I was trying to say is that dillo2 freezes (i.e. gets into a non-resposive state) if you have cookies enabled for www.fltk.org and you start it with that URL. :-) -- Cheers Jorge.-

April 11, 2008

Re: patch: file input

by jcid＠dillo.org

Hi, On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote: > I just stuck it on a label button for now. It looks quite informative. > Already an improvement over Firefox, where I only > find out that I mistyped the filename when the server > doesn't get the file. > > Somewhere that accepts files: http://validator.w3.org > > Edge case that I just noticed: > If I read in a file, delete that file, and try to read it in again > (uses E2EReload), the submit will send the (now empty) file because > a_Capi_get_buf() finds the (now empty) entry in cache. > So I'll have to find out where an a_Cache_entry_remove_by_url() should go. Yes. Please also add a file size threshold, to avoid a dillo exit from an out of memory condition. Committed! -- Cheers Jorge.-

April 11, 2008

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by Johannes.Hofmann＠gmx.de

On Thu, Apr 10, 2008 at 06:08:43PM -0400, Jorge Arellano Cid wrote: > Hi, > > I just committed the implementation of a_Dialog_choice5(). This > function allows for question dialogs with max. 5 options. It is > used by https, and you can test it with "dpi:/hello/". > > As stated above, dpi programs can ask questions by sending a > dpi command and receiving an answer from dillo. > > This implementation is modal, but if there's a need to make it > non-modal, it should be easy to implement choice5 as a class with > internal state and to issue the callback from there. > > Please excuse the late patch, but I had a lot to review and I > still can't trap the freeze on: > > http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 > > (with cookies enabled.) :-P I'm not too worried about that. First, there is still developers focused on fltk2. Second, if eventually fltk-1.3 (or whatever it will be called) should turn out to be better supported, more stable, or have important features I think we can port dillo-fltk over within one or two weeks. Cheers, Johannes

April 11, 2008

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by jcid＠dillo.org

Hi, I just committed the implementation of a_Dialog_choice5(). This function allows for question dialogs with max. 5 options. It is used by https, and you can test it with "dpi:/hello/". As stated above, dpi programs can ask questions by sending a dpi command and receiving an answer from dillo. This implementation is modal, but if there's a need to make it non-modal, it should be easy to implement choice5 as a class with internal state and to issue the callback from there. Please excuse the late patch, but I had a lot to review and I still can't trap the freeze on: http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 (with cookies enabled.) :-P On Sat, Mar 15, 2008 at 07:32:56PM +0100, Christian Kellermann wrote: > Hi Jorge, > > * Jorge Arellano Cid <jcid(a)dillo.org> [080315 18:58]: > > Sorry for the late answer, but I've had little spare time, > > and several topics to answer. > > > > Probably you have already read: > > > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.ht… > > > > an got some info from there. > > Yes, thanks for the hint, it was insightful. I have spend a few > thoughts on the SSL issue and I'd like to hear your opinion on it. > The most work that still needs to be done is to handle certificates > and the user interaction required to make it usable. The user needs > to add trust values to certificates and to add or remove them > offline. I think this can fit well into a server dpi. Adding and > deleting bookmarks could be done similar to handling bookmarks. > Which might be a bit rough but is independent on fltk widgets. I > do think that we already have enough dialog types in dillo. Hard > coding the certificate handling would not make the situation any > better. Yes, dpi bookmarks have proven quite useful a model for this local data-handling case. > Also I can imagine this plugin to handle client certificates which > I do believe will become a more common requirement for certain > applications in the future. Adding secure storage capabilities will > be easy. Also people will have the chance to write some "bridging" > plugin that extracts the needed data from existing storage sources > elsewhere, i.e. certificate servers,... I assume you know more than me about this topic, so feel free to design a simple way to handle it. AFAIS it looks OK. > > Handling this all internally means that we put functionality into > dillo that are needed for, but basically have nothing to do with > browsing. As I have grasped the spirit of this project this may not > be the way to go. A nice thing about handling https internally is > the opportunity to reuse an established connection for more than > one request, which might speed up transfers significantly. I'm not sure on which model will end up being simpler. I'd suggest to design on paper and test the basics before going for a full implementation. HTH. -- Cheers Jorge.-

April 11, 2008

Re: Good news from fltk!

by Johannes.Hofmann＠gmx.de

On Thu, Apr 10, 2008 at 04:36:35PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Apr 10, 2008 at 09:27:06AM -0400, Jorge Arellano Cid wrote: > > > > > > Considering the rendering speed in my old laptops, and what > > > place describes, I guess drawing is taking different function > > > paths in FLTK depending on double-buffering and the detected > > > capabilities of X (something similar to what happens when using > > > the VESA path instead of the native mode with some video cards). > > > > > > Antialiased fonts are extremely slow on his system, and that > > > looks like something fishy is going on. > > > > That's what I think now as well. 4s per page is very slow. > > I almost finished to reinstall my old Extensa 367T which has a > > 200Mhz Pentium and a Neomagic graphics card. It should be pretty > > comparable to the thinkpad 380XD. > > I see that if I switch from 16-bit to 8-bit, drawing a page goes > from 4 seconds to maybe half a second. > > (I'm not using 24-bit because neomagic(4) says "All depths are accelerated > except for depth 24 which is only accelerated on NM2200 and newer models." > This has NM2160.) I'm seeing this now on my old laptop with the Neomagic card. Antialiased fonts are horribly slow. They get pretty fast however if I comment out disable_double_buffer(). I think this is a driver problem, but I will need to do some more tests. Are there any other users with old hardware (slow CPU, but perhaps other graphics card)? Johannes

April 10, 2008

Re: Good news from fltk!

by corvid＠lavabit.com

corvid wrote: > Johannes wrote: > > On Thu, Apr 10, 2008 at 09:27:06AM -0400, Jorge Arellano Cid wrote: > > > > > > Considering the rendering speed in my old laptops, and what > > > place describes, I guess drawing is taking different function > > > paths in FLTK depending on double-buffering and the detected > > > capabilities of X (something similar to what happens when using > > > the VESA path instead of the native mode with some video cards). > > > > > > Antialiased fonts are extremely slow on his system, and that > > > looks like something fishy is going on. > > > > That's what I think now as well. 4s per page is very slow. > > I almost finished to reinstall my old Extensa 367T which has a > > 200Mhz Pentium and a Neomagic graphics card. It should be pretty > > comparable to the thinkpad 380XD. > > I see that if I switch from 16-bit to 8-bit, drawing a page goes > from 4 seconds to maybe half a second. > > (I'm not using 24-bit because neomagic(4) says "All depths are accelerated > except for depth 24 which is only accelerated on NM2200 and newer models." > This has NM2160.) *tries 24-bit anyway* Half a second to redraw. Nice. And I think video is speedier. On the other hand, scrolling in an rxvt is now slow, and I think dragging one around the screen is more sluggish than usual.

April 10, 2008

Re: Good news from fltk!

by corvid＠lavabit.com

Johannes wrote: > On Thu, Apr 10, 2008 at 09:27:06AM -0400, Jorge Arellano Cid wrote: > > > > Considering the rendering speed in my old laptops, and what > > place describes, I guess drawing is taking different function > > paths in FLTK depending on double-buffering and the detected > > capabilities of X (something similar to what happens when using > > the VESA path instead of the native mode with some video cards). > > > > Antialiased fonts are extremely slow on his system, and that > > looks like something fishy is going on. > > That's what I think now as well. 4s per page is very slow. > I almost finished to reinstall my old Extensa 367T which has a > 200Mhz Pentium and a Neomagic graphics card. It should be pretty > comparable to the thinkpad 380XD. I see that if I switch from 16-bit to 8-bit, drawing a page goes from 4 seconds to maybe half a second. (I'm not using 24-bit because neomagic(4) says "All depths are accelerated except for depth 24 which is only accelerated on NM2200 and newer models." This has NM2160.)

April 10, 2008

Re: Good news from fltk!

by Johannes.Hofmann＠gmx.de

On Thu, Apr 10, 2008 at 09:27:06AM -0400, Jorge Arellano Cid wrote: > Hi, > > On Sat, Apr 05, 2008 at 10:42:43PM +0200, Johannes Hofmann wrote: > > Hi, > > > > my first patch broke test programs in dw2/test/ (as they don't use > > clear_double_buffer() as dillo-fltk does). > > Corrected patch attached. > > Committed! > > Great flicker reduction was noticed in my fast computer. I'm yet > to test in the slow one. > > It has been a long struggle against flickering and I can only > feel happy, and grateful, that this is finally ironed out. > > > > [corvid wrote:] > > With clear_double_buffer(), I hit page down on an already-loaded page. > > It takes four seconds to draw the screen of text (well, and then it > > performs a redraw for another three or four seconds). > > If I comment out clear_double_buffer(), it takes no perceived time. > > Some days ago (and before) I've tested dillo2 without Johannes' > patch, in a Thinkpad 380Z, and also with a 385XD. Both render > antialiased fonts much faster than you describe. > > > [Johannes wrote:] > > There is two things I don't understand. First, antialiased fonts > > seem to be extremely slow on your system. What about the test > > programs from fltk, are they usable? Or other programs that use > > antialiased fonts? > > > > Second, commenting out clear_double_buffer() seems to make it faster > > - not just reducing flicker. > > Considering the rendering speed in my old laptops, and what > place describes, I guess drawing is taking different function > paths in FLTK depending on double-buffering and the detected > capabilities of X (something similar to what happens when using > the VESA path instead of the native mode with some video cards). > > Antialiased fonts are extremely slow on his system, and that > looks like something fishy is going on. That's what I think now as well. 4s per page is very slow. I almost finished to reinstall my old Extensa 367T which has a 200Mhz Pentium and a Neomagic graphics card. It should be pretty comparable to the thinkpad 380XD. Cheers, Johannes

April 10, 2008

Re: Good news from fltk!

by corvid＠lavabit.com

Jorge wrote: > > [corvid wrote:] > > With clear_double_buffer(), I hit page down on an already-loaded page. > > It takes four seconds to draw the screen of text (well, and then it > > performs a redraw for another three or four seconds). (Just wanted to mention that the redraw became rare when I tried running with it some more, and went away when I paid enough attention to try to figure out what conditions triggered it...) > > If I comment out clear_double_buffer(), it takes no perceived time. > > Some days ago (and before) I've tested dillo2 without Johannes' > patch, in a Thinkpad 380Z, and also with a 385XD. Both render > antialiased fonts much faster than you describe. > > > [Johannes wrote:] > > There is two things I don't understand. First, antialiased fonts > > seem to be extremely slow on your system. What about the test > > programs from fltk, are they usable? Or other programs that use > > antialiased fonts? > > > > Second, commenting out clear_double_buffer() seems to make it faster > > - not just reducing flicker. > > Considering the rendering speed in my old laptops, and what > place describes, I guess drawing is taking different function > paths in FLTK depending on double-buffering and the detected > capabilities of X (something similar to what happens when using > the VESA path instead of the native mode with some video cards). > > Antialiased fonts are extremely slow on his system, and that > looks like something fishy is going on. Sounds like I'll have to play around with my configuration. I expected it to be slow, so nothing ever drew my suspicion...

April 10, 2008

Re: Good news from fltk!

by jcid＠dillo.org

Hi, On Sat, Apr 05, 2008 at 10:42:43PM +0200, Johannes Hofmann wrote: > Hi, > > my first patch broke test programs in dw2/test/ (as they don't use > clear_double_buffer() as dillo-fltk does). > Corrected patch attached. Committed! Great flicker reduction was noticed in my fast computer. I'm yet to test in the slow one. It has been a long struggle against flickering and I can only feel happy, and grateful, that this is finally ironed out. > [corvid wrote:] > With clear_double_buffer(), I hit page down on an already-loaded page. > It takes four seconds to draw the screen of text (well, and then it > performs a redraw for another three or four seconds). > If I comment out clear_double_buffer(), it takes no perceived time. Some days ago (and before) I've tested dillo2 without Johannes' patch, in a Thinkpad 380Z, and also with a 385XD. Both render antialiased fonts much faster than you describe. > [Johannes wrote:] > There is two things I don't understand. First, antialiased fonts > seem to be extremely slow on your system. What about the test > programs from fltk, are they usable? Or other programs that use > antialiased fonts? > > Second, commenting out clear_double_buffer() seems to make it faster > - not just reducing flicker. Considering the rendering speed in my old laptops, and what place describes, I guess drawing is taking different function paths in FLTK depending on double-buffering and the detected capabilities of X (something similar to what happens when using the VESA path instead of the native mode with some video cards). Antialiased fonts are extremely slow on his system, and that looks like something fishy is going on. Disclaimer: I may be completely wrong on my guess. Finally with regard to making partial double buffering a run time option, I'd prefer to leave it "as is" for now, because it looks like an improvement in all cases so far. -- Cheers Jorge.-

April 10, 2008

Good news from fltk!

by corvid＠lavabit.com

Johannes wrote: > On Wed, Apr 09, 2008 at 04:11:51PM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Apr 08, 2008 at 09:41:33PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > 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()? > > > > > > > > With clear_double_buffer(), I hit page down on an already-loaded page. > > > > It takes four seconds to draw the screen of text (well, and then it > > > > performs a redraw for another three or four seconds). > > > > > > Ouch, 4 seconds is really slow... And there should be now additional > > > redraw in this case. > > > > > > > If I comment out clear_double_buffer(), it takes no perceived time. > > > > > > > > > > This is interesting. I will try to reproduce this on my old laptop. > > > > > > Can you please run xdpyinfo on your machine and check whether or not > > > you have RENDER and XDBE extensions enabled in your X-server? > > > > It shows RENDER. No XDBE, but there is DOUBLE-BUFFER, which Xorg.0.log > > says comes from "dbe". > > Is it misconfigured? I wouldn't be too surprised... > > No, DOUBLE-BUFFER is correct. > > There is two things I don't understand. First, antialiased fonts > seem to be extremely slow on your system. What about the test > programs from fltk, are they usable? Or other programs that use > antialiased fonts? Things are all right as long as I don't insert a clear_double_buffer(). > Second, commenting out clear_double_buffer() seems to make it faster > - not just reducing flicker. I wonder whether there's a way to set double-buffering for menus.

April 9, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

On Wed, Apr 09, 2008 at 04:11:51PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Apr 08, 2008 at 09:41:33PM +0000, corvid wrote: > > > Johannes wrote: > > > > 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()? > > > > > > With clear_double_buffer(), I hit page down on an already-loaded page. > > > It takes four seconds to draw the screen of text (well, and then it > > > performs a redraw for another three or four seconds). > > > > Ouch, 4 seconds is really slow... And there should be now additional > > redraw in this case. > > > > > If I comment out clear_double_buffer(), it takes no perceived time. > > > > > > > This is interesting. I will try to reproduce this on my old laptop. > > > > Can you please run xdpyinfo on your machine and check whether or not > > you have RENDER and XDBE extensions enabled in your X-server? > > It shows RENDER. No XDBE, but there is DOUBLE-BUFFER, which Xorg.0.log > says comes from "dbe". > Is it misconfigured? I wouldn't be too surprised... No, DOUBLE-BUFFER is correct. There is two things I don't understand. First, antialiased fonts seem to be extremely slow on your system. What about the test programs from fltk, are they usable? Or other programs that use antialiased fonts? Second, commenting out clear_double_buffer() seems to make it faster - not just reducing flicker. Johannes

April 9, 2008

Good news from fltk!

by corvid＠lavabit.com

Johannes wrote: > On Tue, Apr 08, 2008 at 09:41:33PM +0000, corvid wrote: > > Johannes wrote: > > > 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()? > > > > With clear_double_buffer(), I hit page down on an already-loaded page. > > It takes four seconds to draw the screen of text (well, and then it > > performs a redraw for another three or four seconds). > > Ouch, 4 seconds is really slow... And there should be now additional > redraw in this case. > > > If I comment out clear_double_buffer(), it takes no perceived time. > > > > This is interesting. I will try to reproduce this on my old laptop. > > Can you please run xdpyinfo on your machine and check whether or not > you have RENDER and XDBE extensions enabled in your X-server? It shows RENDER. No XDBE, but there is DOUBLE-BUFFER, which Xorg.0.log says comes from "dbe". Is it misconfigured? I wouldn't be too surprised... > > (If you think that's bad, I used a Commodore until 1993 -- if you're > > old enough for that to mean much to you, anyway). > > Old enough - yes, but I had an Atari 800XL back then :-) Yeah, I remembered after I sent it that the 8-bit world survived a long time in Germany, and so that was bound to sound relatively sane. And dillo in 2008 draws a certain sort of person anyway.

April 9, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

On Tue, Apr 08, 2008 at 09:41:33PM +0000, corvid wrote: > Johannes wrote: > > 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()? > > With clear_double_buffer(), I hit page down on an already-loaded page. > It takes four seconds to draw the screen of text (well, and then it > performs a redraw for another three or four seconds). Ouch, 4 seconds is really slow... And there should be now additional redraw in this case. > If I comment out clear_double_buffer(), it takes no perceived time. > This is interesting. I will try to reproduce this on my old laptop. Can you please run xdpyinfo on your machine and check whether or not you have RENDER and XDBE extensions enabled in your X-server? > > > 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... > > a thinkpad 380XD. It had its tenth birthday in February. > I've been really meaning to get something newer for... a year now. > (If you think that's bad, I used a Commodore until 1993 -- if you're > old enough for that to mean much to you, anyway). Old enough - yes, but I had an Atari 800XL back then :-) > > > > > > > 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. > > It currently must take like a minute to go from one item to the next. > Probably more. I'll try --disable-xft. > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 9, 2008