- Dillo-dev - lists.mailman3.com

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

Re: patch: url encode, append input

by jcid＠dillo.org

On Tue, Apr 08, 2008 at 09:16:47PM +0000, corvid wrote: > Jorge wrote: > > 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. > > Ohh... I thought RFC 1867 was just an old version of > RFC 2388 (Returning Values from Forms: multipart/form-data), > so I never looked at it. Yeah, browsing RFC dependencies is confusing sometimes... Jukka Korpela usually has pretty solid advice: http://www.cs.tut.fi/~jkorpela/forms/file.html#rfc The whole page is insightful, the anchor points to: "The status of RFC 1867" > I'd prefer not to send the file at all if we don't have to. After reading the document quickly, I'd also prefer not to send the file. Please let me know your thoughts. -- Cheers Jorge.-

April 9, 2008

Good news from fltk!

by corvid＠lavabit.com

Oh wow. Sure, I knew that antialiasing slows things down, but I'd never imagined the difference was so incredibly dramatic. It's now fine with clear_double_buffer(), and the menu I'd mentioned now goes at _full_ _speed_.

April 9, 2008

Good news from fltk!

by corvid＠lavabit.com

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). If I comment out clear_double_buffer(), it takes no perceived time. > 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). > > > > 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.

April 8, 2008

Re: patch: url encode, append input

by corvid＠lavabit.com

Jorge wrote: > 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. Ohh... I thought RFC 1867 was just an old version of RFC 2388 (Returning Values from Forms: multipart/form-data), so I never looked at it. I'd prefer not to send the file at all if we don't have to.

April 8, 2008

Re: patch: urldecode base64 data uri

by jcid＠dillo.org

On Sun, Apr 06, 2008 at 07:01:52PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Apr 06, 2008 at 05:07:30AM +0000, corvid wrote: > > > I took a better look at the RFC and it looks like I am wrong. > > > > > > I naively assumed that since it's been on the acid site for however > > > many years, somebody would have complained if it wasn't right, > > > and I took relatively little care in rfc-checking. > > > > > > On the other hand, I am coming to learn that RFCs are > > > not perfectly perfect things. > > > > > > The relevant RFC text: > > > The appearance of ";base64" means that the data > > > is encoded as base64. Without ";base64", the data (as a sequence of > > > octets) is represented using ASCII encoding for octets inside the > > > range of safe URL characters and using the standard %xx hex encoding > > > of URLs for octets outside that range. > > > > > > http://www.webstandards.org/action/acid2/guide/ says of the square: > > > Also, there is a 64px by 64px red box in the background (represented > > > by the PNG image in the data url, not reprinted in full). The red > > > box is not visible as the background-attachment is set to 'fixed' > > > which puts the red box outside of view. > > > > > > (as opposed to saying that it's supposed to break or something) > > > > Which in what regards to the patch, means? > > > > a) keep > > b) revert > > - To me, a strict reading of the RFC says revert. > > - I see that http://developer.mozilla.org/en/docs/The_data_URL_scheme > gives their base64 example as > "data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D" > > - At http://simonwillison.net/2003/Aug/11/selfContained/ > Simon Proctor claimed that Mozilla didn't like the URL encoding, > and Ian Hickson asserted that it was necessary. > > - Ian Hickson would appear to be the guy who wrote the "data: URI kitchen" > (http://software.hixie.ch/utilities/cgi/data/data) which is apparently > the main datauri-maker that people use, as well as being the guy who wrote > the acid2 test. > > On one hand, this means that dillo will encounter the URL encoding. > > On the other hand, if Hickson has any actual persuasive argument for > his viewpoint, I have not found it. OK, reverted. -- Cheers Jorge.-

April 8, 2008