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

[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