- Dillo-dev - lists.mailman3.com

Scrolling patch!

by jcid＠dillo.org

On Thu, Oct 25, 2007 at 08:15:24PM +0200, Matthias Franz wrote: > On Wed, Oct 24, 2007 at 05:27:42PM -0300, Jorge Arellano Cid wrote: > > > I see this in two parts: > > > > > > 1.- Remembering the scroll position in each bw's nav_stack > > > 2.- Making fragments push a new page (and not just jump like now). > > > > Number 1.- is commited! > > Hi Jorge, > > I think it's a good idea to split this into two parts. If people have > different preferences about (2), one could make this configurable. > > Here is a problem with the current version: > > Create two (long) pages. At the bottom of each page make a link to > the other one. Now do the following: Start dillo2 with page 1. > The top of the page is shown. Scroll to the bottom, click on the link. > Now page 2 opens (at the top). Scroll to the bottom, click on the link. > Now page 1 opens (at the top). Scroll to the bottom. > Go back to page 2. The bottom is shown. Go forward to page 1. > Now the top is shown, although you left the page at the bottom. > > Can you reproduce this? Yes, and as a bonus I get hit by the not-completely-rendered-yet scrolling offset bug! :-) It was a lapsus of mine. Small patch commited. You can debug with (e.g.): ./dillo-fltk /tmp/page1.html |grep -e ^Nav -- Cheers Jorge.-

Oct. 25, 2007

Re: new browser windows slower than first one

by place＠gobigwest.com

I think my biggest problem is that I can't read a page until it's finished downloading because it's spending the whole time redrawing, redrawing, redrawing.

Oct. 25, 2007

Re: new browser windows slower than first one

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Thu, Oct 25, 2007 at 04:10:12PM -0300, Jorge Arellano Cid wrote: > Hi, > > On Mon, Oct 22, 2007 at 06:39:09PM +0000, place wrote: > > Turning off double buffering means that the default code from the tree > > is unusably slow and annoying on my ancient(*) computer. This might dissuade > > someone who comes along at the wrong time intending to give the fltk dillo > > a look. > > > > Though admittedly it might be my configuration... > > When testing in a Pentium I, 233Mhz, 96MB ram, the results were > mixed, varied and confusing to me! > > For instance with dillo2-noDB, I get faster scrolling in a > down-arrow-always-pressed-test, varying from 25% to 95% more or > less of CPU depending on what is to be rendered and the X > server's internal memory usage. Mouse drag-scrolling sometimes is > better, some others worst and others the same !? > > With dillo2-DB, sometimes I get faster mouse drag-scrolling, > others the same. Down-arrow-always-pressed-test is consistently > worst, but sometimes pages render much faster and others the > same. > > Frankly, I don't understand what this means. Yes, the performance is pretty confusing sometimes. The main drawback for me of standard DB dillo is that CPU usage and server side memory consumption gets horrible on my laptop when I open 5 or more windows. > > Ah, I also noticed that in a fast machine dillo2-noDB is much > better than dillo2-DB (but annoying at flickering). I think, we need something like DB for drawing. Dillo1 also draws to a backbuffer and then copies the result to the screen - please correct me if I'm wrong. As dillo first draws the background and then the text/images on top, we will always see annoying flickering if we draw directly to the screen, especially with frequent redraws during incremental page rendering while the page is loaded (which is a great feature of dillo btw). However, I hope that we can do better than switch on DB generally. As dillo is single threaded even for multiple windows, we could use a single backbuffer for all windows. I've got this working, but unfortunately currently only if XFT is disabled. Johannes

Oct. 25, 2007

Re: new browser windows slower than first one

by jcid＠dillo.org

Hi, On Mon, Oct 22, 2007 at 06:39:09PM +0000, place wrote: > Turning off double buffering means that the default code from the tree > is unusably slow and annoying on my ancient(*) computer. This might dissuade > someone who comes along at the wrong time intending to give the fltk dillo > a look. > > Though admittedly it might be my configuration... When testing in a Pentium I, 233Mhz, 96MB ram, the results were mixed, varied and confusing to me! For instance with dillo2-noDB, I get faster scrolling in a down-arrow-always-pressed-test, varying from 25% to 95% more or less of CPU depending on what is to be rendered and the X server's internal memory usage. Mouse drag-scrolling sometimes is better, some others worst and others the same !? With dillo2-DB, sometimes I get faster mouse drag-scrolling, others the same. Down-arrow-always-pressed-test is consistently worst, but sometimes pages render much faster and others the same. Frankly, I don't understand what this means. Ah, I also noticed that in a fast machine dillo2-noDB is much better than dillo2-DB (but annoying at flickering). -- Cheers Jorge.-

Oct. 25, 2007

Scrolling patch!

by matthias.franz＠ujf-grenoble.fr

On Wed, Oct 24, 2007 at 05:27:42PM -0300, Jorge Arellano Cid wrote: > > I see this in two parts: > > > > 1.- Remembering the scroll position in each bw's nav_stack > > 2.- Making fragments push a new page (and not just jump like now). > > Number 1.- is commited! Hi Jorge, I think it's a good idea to split this into two parts. If people have different preferences about (2), one could make this configurable. Here is a problem with the current version: Create two (long) pages. At the bottom of each page make a link to the other one. Now do the following: Start dillo2 with page 1. The top of the page is shown. Scroll to the bottom, click on the link. Now page 2 opens (at the top). Scroll to the bottom, click on the link. Now page 1 opens (at the top). Scroll to the bottom. Go back to page 2. The bottom is shown. Go forward to page 1. Now the top is shown, although you left the page at the bottom. Can you reproduce this? Cheers, -- Matthias Franz

Oct. 25, 2007

Scrolling patch!

by jcid＠dillo.org

On Mon, Oct 22, 2007 at 07:12:28PM -0300, Jorge Arellano Cid wrote: > Hi > > > [...] > > Maybe this is a good time to remember a patch of mine that I sent > > to Jorge (not to dillo-dev) more than 2 years ago (for Dillo1, of > > course). It changed the way the scrolling position is remembered so > > that, I think, dillo becomes more user friendly. In Dillo[12], the > > scrolling position is associated to a URL. This means that when > > displaying a page which is already in the history list, the old > > position is restored (no matter whether one uses the same window or > > another). With the patch, there is a separate scrolling position for > > each item in the history list. This means that each click on a link > > opens a page at the beginning (or at the position specified by the tag > > if there is one). I find this natural and sometimes even important: > > Consider some manual on several web pages where a link takes you to > > the definition of some function etc. If you click on a link, you don't > > care if the definition you want to see is on a page where you have > > been before (or maybe even the same page); you just want to open the > > new page there where the relevant information is, and going one page > > back should bring you to the page where you clicked on the link (even > > if it is the same page). > > Yes. > > I see this in two parts: > > 1.- Remembering the scroll position in each bw's nav_stack > 2.- Making fragments push a new page (and not just jump like now). > > Number 1.- is cooking here... :-) Number 1.- is commited! Note: this a long patch, and some glitches remain, but it looks like a good basis to improve upon. For instance, sometimes the page will not scroll to the point were it was (race condition, because most of the time it works), but the scrolling pos. is correctly kept and set, so it looks like a rendering glitch. -- Cheers Jorge.-

Oct. 24, 2007

Re: new browser windows slower than first one

by jcid＠dillo.org

Hi, On Mon, Oct 22, 2007 at 06:39:09PM +0000, place wrote: > Turning off double buffering means that the default code from the tree > is unusably slow and annoying on my ancient(*) computer. This might dissuade > someone who comes along at the wrong time intending to give the fltk dillo > a look. > > Though admittedly it might be my configuration... I'll try to check this on wednesday, in a slow machine. > * Computers never get slow; software gets slow! TRUE. -- Cheers Jorge.-

Oct. 23, 2007

Scrolling patch!

by jcid＠dillo.org

Hi > [...] > Maybe this is a good time to remember a patch of mine that I sent > to Jorge (not to dillo-dev) more than 2 years ago (for Dillo1, of > course). It changed the way the scrolling position is remembered so > that, I think, dillo becomes more user friendly. In Dillo[12], the > scrolling position is associated to a URL. This means that when > displaying a page which is already in the history list, the old > position is restored (no matter whether one uses the same window or > another). With the patch, there is a separate scrolling position for > each item in the history list. This means that each click on a link > opens a page at the beginning (or at the position specified by the tag > if there is one). I find this natural and sometimes even important: > Consider some manual on several web pages where a link takes you to > the definition of some function etc. If you click on a link, you don't > care if the definition you want to see is on a page where you have > been before (or maybe even the same page); you just want to open the > new page there where the relevant information is, and going one page > back should bring you to the page where you clicked on the link (even > if it is the same page). Yes. I see this in two parts: 1.- Remembering the scroll position in each bw's nav_stack 2.- Making fragments push a new page (and not just jump like now). Number 1.- is cooking here... :-) -- Cheers Jorge.-

Oct. 23, 2007

Re: new browser windows slower than first one

by place＠gobigwest.com

Turning off double buffering means that the default code from the tree is unusably slow and annoying on my ancient(*) computer. This might dissuade someone who comes along at the wrong time intending to give the fltk dillo a look. Though admittedly it might be my configuration... * Computers never get slow; software gets slow!

Oct. 22, 2007

directory listings?

by bogus＠does.not.exist.com

Hi, On Mon, Oct 22, 2007 at 09:13:01AM +0200, Jan Stary wrote: > On Oct 19 19:33:56, dillo-dev-bounces(a)dillo.org wrote: > > On Thu, Oct 18, 2007 at 02:27:57PM +0200, Jan Stary wrote: > > > Hi all, > > > > > > dillo-fltk http://stare.cz/~hans/foto/ gives me a directory > > > listing as it should. It's full of subdirectories, and they > > > are all the same (just contain JPEGs). > > > > > > Now when I click on _some_ of the links, I get a correct directory > > > listing again (of the subdirectory). When I click on _some_ others > > > I get nothing, just a blank page (gray). > > > > > > [...] > > > > Please try the CVS code on this. > > With current code, I cannot even test it, because > dillo keeps "Connecting to server" forever, > giving the following message: > > > $ dillo-fltk http://stare.cz/~hans/foto/ > prefs: Can't open dillorc2 file: /home/hans/.dillo/dillorc2 > prefs: Can't open dillorc2 file: /usr/local/etc/dillorc > prefs: Using internal defaults. > dillo_dns_init: Here we go! (threaded) > Enabling cookies as from cookiesrc... > Nav_open_url: Url=>http://stare.cz/~hans/foto/< > Dns_server [0]: stare.cz is 0x7f7b8640 > Connecting to 88.208.90.43 > ** ERROR **: IO_fd_write_cb: call on already closed io! > a_UIcmd_close_bw > > ... until I kill it. > > (The server is acessible, the same URL can be browsed with lynx.) Yes, that's a race condition I have to debug. Just try it several times (start browser close, try another). It will eventually succeed... -- Cheers Jorge.-

Oct. 22, 2007