- Dillo-dev - lists.mailman3.com

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

directory listings?

by hans＠stare.cz

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.) Jan

Oct. 22, 2007

Re: new browser windows slower than first one

by matthias.franz＠ujf-grenoble.fr

On Sun, Oct 21, 2007 at 03:35:49PM +0200, Johannes Hofmann wrote: > switches double-buffering off. This makes quite a difference for > scrolling here. Scrolling an empty page at fullscreen now consumes 1.5% CPU load and not 100% as before. Fantastic!!! If the page has content, it's considerably more (at least 20%), most likely because of the many unneccessary redraws. Cheers, -- Matthias Franz

Oct. 21, 2007

Re: new browser windows slower than first one

by bogus＠does.not.exist.com

Hi, On Sun, Oct 21, 2007 at 03:35:49PM +0200, Johannes Hofmann wrote: > On Sat, Oct 20, 2007 at 08:14:47PM +0200, Johannes Hofmann wrote: > > Hello, > > > > just noticed a scroll performance-related problem: > > When I create many browser windows (e.g. using the middle mouse > > button), srolling in these created windows causes more Xorg CPU > > usage than in the first one. > > Maybe, scrolling in the new windows causes redraws from the old > > ones? > > Argh, fltk2 uses double-buffering by default. This uses quite some > memory on the X-server side and slows things down. > > --- a/src/ui.cc Sat Oct 20 17:59:33 2007 +0200 > +++ b/src/ui.cc Sun Oct 21 14:47:49 2007 +0200 > @@ -580,6 +580,7 @@ UI::UI(int win_w, int win_h, const char* > { > int s_h = 20; > resizable(this); > + clear_double_buffer(); > begin(); > TopGroup = this; > > > switches double-buffering off. This makes quite a difference for > scrolling here. However during rendering there is some flicker now. > But the excessive redraws that cause the flicker should be > addressed anyhow. Commited! This is will be very good for debugging screen updates. Those not working in it can comment it out in src/ui.cc: + //clear_double_buffer(); -- Cheers Jorge.-

Oct. 21, 2007

drag scrolling as in good old dillo1

by bogus＠does.not.exist.com

On Sat, Oct 20, 2007 at 01:06:41PM +0200, Johannes Hofmann wrote: > Hi, > > here is a patch to enable drag scrolling with the middle mouse > button as in dillo1. Done. > For me from now only the "Backspace" hotkey is missing for daily > browsing - apart from the occasional crashes of course :-) :-) -- Cheers Jorge.-

Oct. 21, 2007

Re: new browser windows slower than first one

by Johannes.Hofmann＠gmx.de

On Sat, Oct 20, 2007 at 08:14:47PM +0200, Johannes Hofmann wrote: > Hello, > > just noticed a scroll performance-related problem: > When I create many browser windows (e.g. using the middle mouse > button), srolling in these created windows causes more Xorg CPU > usage than in the first one. > Maybe, scrolling in the new windows causes redraws from the old > ones? Argh, fltk2 uses double-buffering by default. This uses quite some memory on the X-server side and slows things down. --- a/src/ui.cc Sat Oct 20 17:59:33 2007 +0200 +++ b/src/ui.cc Sun Oct 21 14:47:49 2007 +0200 @@ -580,6 +580,7 @@ UI::UI(int win_w, int win_h, const char* { int s_h = 20; resizable(this); + clear_double_buffer(); begin(); TopGroup = this; switches double-buffering off. This makes quite a difference for scrolling here. However during rendering there is some flicker now. But the excessive redraws that cause the flicker should be addressed anyhow. Johannes

Oct. 21, 2007

new browser windows slower than first one

by Johannes.Hofmann＠gmx.de

Hello, just noticed a scroll performance-related problem: When I create many browser windows (e.g. using the middle mouse button), srolling in these created windows causes more Xorg CPU usage than in the first one. Maybe, scrolling in the new windows causes redraws from the old ones? Johannes

Oct. 20, 2007

Scrolling patch!

by matthias.franz＠ujf-grenoble.fr

On Fri, Oct 19, 2007 at 07:09:49PM -0300, dillo-dev-bounces(a)dillo.org wrote: > Here's a patch I wanted to add since a long time. Remembering > the scroll position in a page. At least for me, it improves web > browsing a lot! Hi Jorge, this patch is really helpful!!! 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). The patch, which was against dillo1 CVS from 2005-01-05, can be found at http://www-fourier.ujf-grenoble.fr/~franz/dillo/dillo-CVS20050105-history.d… It is quite long because it changed some data types which were used everywhere, but I would like to point out that the resulting binary was not bigger than before (rather on the contrary, if I remember correctly). Below I include the email to Jorge where I explain the patch. As I've already written in another email, I'm quite busy with other things right now. Maybe this patch is still useful for others. ===== from email to Jorge, 2005-01-06 ===== DETAILED DESCRIPTION #################### FIXED BUGS: * BUG#569: Links to the same page are not recorded in the history list. * BUG#581: Reloading an URL with fragment identifier doesn't keep the page position. * The scrolling positions of a page are initialised to 0 (new: -1). This way one cannot safely tell whether a page has already been displayed. Test: Load an URL with fragment identifier, move to the very top of the page, click back button, click forward button. Now you are again at the anchor position. * Jumping to an anchor position in Nav_open_url is premature: Try to open some non-existing URL with fragment identifier #anchor. Then Dillo jumps to #anchor on the current page (if such an anchor exists). * Some others that I'm to lazy to describe. (Changing settings before the new page has arrived, see below.) CHANGES: * The real changes (described below) happen in nav.[ch], url.[ch], a_Web_dispatch_by_type and Html_close. The files history.[ch] are removed (see below). * Look first a Nav_open_url, a_Nav_expect_done and a_Web_dispatch_by_type. Now a_Nav_expect_done is called for every page (it should better be called a_Nav_open_url_finish). I've moved many things from Nav_open_url and a_Web_dispatch_by_type to a_Nav_expect_done, either because the code was similar, or because many things should only be done when the new page has arrived, for example saving the scrolling position of the current page or clearing the page menu. * In Nav_open_url, the navigation index nav_stack_ptr is not changed any more; instead the new position is stored in nav_expect_ptr. The reason is that otherwise one cannot save the current scrolling position in a_Nav_expect_done, because one doesn't know any more what was the current page. * The scrolling position is not stored in DilloUrl anymore, but in the navigation list (or stack). The list items are now of the new type NavItem (browser.h): /* navigation list item */ typedef struct { DilloUrl *url; const gchar *title; gint posx; /* -1 if page has not been displayed */ gint posy; } NavItem; This is also the place where form data should be kept so that Dillo remembers the filled-in values in the history list. (This is another patch I'm planning.) * Before, the navigation list only kept indices to the history list (history.h): typedef struct { DilloUrl *url; gchar *title; } H_Item; * Global history list */ static H_Item *history = NULL; static gint history_size = 0; /* [1 based] */ static gint history_size_max = 16; This additional referencing from the navigation list to the history list seemed to me very weird. I guess the history list is still from a time where Dillo didn't support multiple browser windows. As you can see, I've completely removed the history list. Consequence: The files history.[ch] are completely REMOVED. * BUG#581 actually had two reasons. One was located in nav.c (now fixed as a by-product), the other was the following: Restoring a previous scrolling position in a_Web_dispatch_by_type doesn't always work because at that time the page is being rendered. If there one calls a_Dw_gtk_scrolled_window_set_scrolling_position with a position that doesn't fit on the page (because rendering hasn't reached that position yet), the call is ignored. Current patch: Restore the scrolling position after rendering has been finished in Html_close. This works, but it is not optimal. A better solution would be as for anchors: Anchor positions can be set even if the anchor place hasn't been rendered yet. But I think this should be done by a dw_* specialist. CODE STATUS: * The code seems to be stable. * PROBLEM: When going through the history list, it takes at lot of time before the new page is displayed. (Try a long page like the HTML 3.2 spec.) Before, switching was only done after some time (I think when the page was rendered), now the switching is immediately, which gives you a blank page for a fraction of a second before the new page content is displayed. This is particularly noticable when you change between two pages with different background colours. * There is still a small scrolling position problem: Sometimes when I come back to a previously displayed page (using back/forward), the scrolling position has changed somewhat (up to 1/3 of a screen). But this happens with the unpatched Dillo as well, so it seems to be a separate bug. * The code might still need a bit polishing. ===== end email ===== Cheers, -- Matthias Franz

Oct. 20, 2007

drag scrolling as in good old dillo1

by Johannes.Hofmann＠gmx.de

Hi, here is a patch to enable drag scrolling with the middle mouse button as in dillo1. For me from now only the "Backspace" hotkey is missing for daily browsing - apart from the occasional crashes of course :-) Johannes diff --git a/dw/fltkviewport.cc b/dw/fltkviewport.cc --- a/dw/fltkviewport.cc +++ b/dw/fltkviewport.cc @@ -47,6 +47,7 @@ FltkViewport::FltkViewport (int x, int y vscrollbar->callback (vscrollbarCallback, this); scrollX = scrollY = 0; + dragScrolling = 0; gadgetOrientation[0] = GADGET_HORIZONTAL; gadgetOrientation[1] = GADGET_HORIZONTAL; @@ -202,6 +203,34 @@ int FltkViewport::handle (int event) /** \bug Undraw focus box. */ return 1; + case ::fltk::PUSH: + if (::fltk::event_button() == ::fltk::MiddleButton) { + dragScrolling = 1; + dragX = ::fltk::event_x(); + dragY = ::fltk::event_y(); + /* pass event so that middle click can open link in new window */ + FltkWidgetView::handle (event); + return 1; + } + break; + + case ::fltk::DRAG: + if (::fltk::event_button() == ::fltk::MiddleButton) { + if (dragScrolling) { + scroll(dragX - ::fltk::event_x(), dragY - ::fltk::event_y()); + dragX = ::fltk::event_x(); + dragY = ::fltk::event_y(); + return 1; + } + } + break; + + case ::fltk::RELEASE: + if (::fltk::event_button() == ::fltk::MiddleButton) { + dragScrolling = 0; + } + break; + case ::fltk::SHORTCUT: switch (::fltk::event_key()) { case PageUpKey: @@ -236,12 +265,9 @@ int FltkViewport::handle (int event) scrollTo (canvasWidth, canvasHeight); /* gets adjusted in scroll() */ return 1; } + } - return FltkWidgetView::handle (event); - - default: - return FltkWidgetView::handle (event); - } + return FltkWidgetView::handle (event); } // ---------------------------------------------------------------------- diff --git a/dw/fltkviewport.hh b/dw/fltkviewport.hh --- a/dw/fltkviewport.hh +++ b/dw/fltkviewport.hh @@ -21,6 +21,7 @@ private: int scrollX, scrollY; int scrollDX, scrollDY; + int dragScrolling, dragX, dragY; ::fltk::Scrollbar *vscrollbar, *hscrollbar;

Oct. 20, 2007

Scrolling patch!

by Johannes.Hofmann＠gmx.de

> Hi there, > > Here's a patch I wanted to add since a long time. Remembering > the scroll position in a page. At least for me, it improves web > browsing a lot! Very nice! This was really missing. Johannes

Oct. 20, 2007

Re: bug: non-ascii characters not displayed correctly in the title bar

by matthias.franz＠ujf-grenoble.fr

On Fri, Oct 19, 2007 at 07:05:07PM -0300, dillo-dev-bounces(a)dillo.org wrote: > Can you display special characters in you terminal prompt? > e.g.: > > server$ ??? yes Dillo1 displays the title bar correctly. I use icewm as window manager. I have compiled fltk2 with --disable-xft. -- Matthias Franz

Oct. 20, 2007

directory listings?

by bogus＠does.not.exist.com

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. -- Cheers Jorge.-

Oct. 20, 2007

Scrolling patch!

by bogus＠does.not.exist.com

Hi there, Here's a patch I wanted to add since a long time. Remembering the scroll position in a page. At least for me, it improves web browsing a lot! The dw2 part of the patch is attached to this email, so Sebastian can look at a minor change that looks like a fix for a hidden bug in the code... The patch is complete in CVS. -- Cheers Jorge.-

Oct. 20, 2007

bug: non-ascii characters not displayed correctly in the title bar

by bogus＠does.not.exist.com

On Fri, Oct 19, 2007 at 08:49:48PM +0200, Matthias Franz wrote: > Hi, > > by default, I use Latin1 encoding on my machine, not UTF-8. > Dillo2 does not do UTF-8 -> Latin1 conversion for the title bar. > Here is an example: > > <title>dillô</title> > <body> > dillô > </body> > > You don't get "dill?" in the title bar, but "dill??". Strange, it works for me either with "en" or "latin1". I don't use utf-8 with mrxvt. Can you display special characters in you terminal prompt? e.g.: server$ ??? -- Cheers Jorge.-

Oct. 20, 2007

bug: non-ascii characters not displayed correctly in the title bar

by matthias.franz＠ujf-grenoble.fr

Hi, by default, I use Latin1 encoding on my machine, not UTF-8. Dillo2 does not do UTF-8 -> Latin1 conversion for the title bar. Here is an example: <title>dillô</title> <body> dillô </body> You don't get "dill?" in the title bar, but "dill??". Cheers, -- Matthias Franz

Oct. 19, 2007

dillo crashes on (incorrect) tables

by matthias.franz＠ujf-grenoble.fr

Hi, the following (syntactically incorrect) HTML code makes dillo2 crash on my machine. Dillo1 is fine. <html> <table> <tr></tr> <tr><td colspan="3"></td></tr> <td colspan="3"> </table> </html> Cheers, -- Matthias Franz

Oct. 19, 2007

Re: receiver patch: html page menu working, image menu present but not called.

by place＠gobigwest.com

Jorge wrote: > On Thu, Oct 18, 2007 at 10:56:39PM +0000, place wrote: > > > The fact of the linkblock not being freed in current code (see warning > > > from compiling html.cc) is just because I haven't found the clean & proper > > > place to hook Html_lb_free() (to widget destruction probably). IIRC there > > > was a ...connect_after() hook in GTK that worked ok after deletion of the > > > object (which I haven't yet found an analog in FLTK2). > > > > So I should regard "linkblock" as "the bag of event handling stuff"? Okay. > > It's a bag for links, form data etc... > > I've longed to get rid of it several times, but I don't see a > much cleaner approach. This may be the time, or maybe not. > > For instance, if the linkblock data is put inside the html > struct, and the whole turned into a class, it would look much > cleaner. It would also be clearer in the case of plain text (it > also receives the signal for page menu), and having a separate > linkblock or receiver for it seems odd. > > OTOH, the data that now belongs to the html-struct is freed > when parsing finishes, and it would remain inside the class, > which is a bit untidy, but if we make this part a pointer inside > the shiny new class, it could go NULL at freeing time. This looks > cleaner. Indeed. > > I now have new code for image signals. In an effort not to add an extra argument > > to the signals (which seemed hacky -- either an image_vs_link sort of argument, > > or an image_number sort of argument), I ended up making a vector of image > > receivers, one per image. I can't decide whether that is bad or reasonably > > sensible. If a better solution is obvious to you, please let me know. > > Not obvious, but I think of the case of pages with hundreds or > thousands of images (e.g.): > > http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/… > > Memory consumption for this vector may grow too much. A single > int value working as an index to the proper URL/data from within > a single image signal receiver looks cleaner (from a distance :-) All right. > > So the image menu works, an ugly little button toggles image loading, and > > click-to-load works, though I don't have any placeholder image. > > More than enough for a start! And an opportunity for people who say "I'd love to help dillo, but don't know how to write code" to make a little tiny button... I was going to try having a single patch for all of that, but it was already teetering on the edge between small-enough and too-much. I think I'll try to pull out the menu and the button to send you first, since they're harmless, and then the rest after I redo it. > > (if only forms worked well enough to perform search queries, > > I just about wouldn't need my old dillo around anymore!) > > I know what you mean. Given that, plus the scrolling bug, > search text inside pages and anchors, it'd looks very sexy to me! > > > > BTW, not that it really matters at present, but I discovered that > > in Html_write_raw(), you can get token_start to be greater than bufsize. > > Go through the verbatim part at the top until token_start = buf_index = bufsize, > > then have the isspace() test right below it be true. > > It looks like this is why my iconv buffer code crashed often on me. > > Thanks for the report, I'll look at it when I find some time. > > > BTW, this duscussion is more than worth to have in dillo-dev. > Can I take it there? *cc:s dillo-dev, resists urge to trim quotes*

Oct. 19, 2007

./configure confused about FLTK version

by bogus＠does.not.exist.com

On Fri, Oct 19, 2007 at 03:33:14PM +0200, Johannes Hofmann wrote: > > > > Some time ago they were deciding whether {fltk,fltk2}-config. > > If you're sure they decided for fltk2-config finally, I'd commit. > > Currently it's fltk2-config. They might switch back, but I don't > think this will happen any time soon. OK, I can point at you then! :-) Done. BTW Jan, for the record, did the other patch work? -- Cheers Jorge.-

Oct. 19, 2007

[patch] CPU usage when moving mouse on large page

by Johannes.Hofmann＠gmx.de

Hi, here is another patch regarding the performance of dillo-fltk. It addresses the high CPU usage when moving the cursor on a large page especially if it contains many links and images. See http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/… as an example. Note, that also dillo1 uses quite some CPU when moving the mouse on that page. The patch moves Layout::getWidgetAtPoint0() to Widget::getWidgetAtPoint() and makes it virtual so that widgets can provide an own optimzed version of that method. For the Textblock widget an optimized version is implemented that uses findLineIndex(). This patch is a bit more invasive than the scroll-patch, so I would appreciate comments from the dw author(s). Johannes diff --git a/dw/layout.cc b/dw/layout.cc --- a/dw/layout.cc +++ b/dw/layout.cc @@ -703,47 +703,6 @@ void Layout::leaveNotify (View *view, Bu } } -/** - * \brief Search recursively through widget. - * - * Used by dw::core::Layout:getWidgetAtPoint. - */ -Widget *Layout::getWidgetAtPoint0 (Widget *widget, int x, int y, int level) -{ - Iterator *it; - Widget *childAtPoint; - - //_MSG ("%*s-> examining the %s %p (%d, %d, %d x (%d + %d))\n", - // 3 * level, "", gtk_type_name (GTK_OBJECT_TYPE (widget)), widget, - // widget->allocation.x, widget->allocation.y, - // widget->allocation.width, widget->allocation.ascent, - // widget->allocation.descent); - - if (x >= widget->allocation.x && - y >= widget->allocation.y && - x <= widget->allocation.x + widget->allocation.width && - y <= widget->allocation.y + widget->getHeight ()) { - //_MSG ("%*s -> inside\n", 3 * level, ""); - /* - * Iterate over the children of this widget. Test recursively, whether - * the point is within the child (or one of its children...). If there - * is such a child, it is returned. Otherwise, this widget is returned. - */ - childAtPoint = NULL; - it = widget->iterator (Content::WIDGET, false); - - while (childAtPoint == NULL && it->next ()) - childAtPoint = getWidgetAtPoint0 (it->getContent()->widget, - x, y, level + 1); - - if (childAtPoint) - return childAtPoint; - else - return widget; - } else - return NULL; -} - /* * Return the widget at position (x, y). Return NULL, if there is no widget. */ @@ -752,7 +711,7 @@ Widget *Layout::getWidgetAtPoint (int x, //_MSG ("------------------------------------------------------------\n"); //_MSG ("widget at (%d, %d)\n", x, y); if (topLevel) - return getWidgetAtPoint0 (topLevel, x, y, 0); + return topLevel->getWidgetAtPoint (x, y, 0); else return NULL; } diff --git a/dw/layout.hh b/dw/layout.hh --- a/dw/layout.hh +++ b/dw/layout.hh @@ -87,7 +87,6 @@ private: enum ButtonEventType { BUTTON_PRESS, BUTTON_RELEASE, MOTION_NOTIFY }; - Widget *getWidgetAtPoint0 (Widget *widget, int x, int y, int level); Widget *getWidgetAtPoint (int x, int y); void moveToWidget (Widget *newWidgetAtPoint, ButtonState state); diff --git a/dw/textblock.cc b/dw/textblock.cc --- a/dw/textblock.cc +++ b/dw/textblock.cc @@ -1730,6 +1730,50 @@ void Textblock::addLinebreak (core::styl wordWrap (words->size () - 1); } + +/** + * \brief Search recursively through widget. + * + * This is an optimized version of the general + * dw::core::Widget::getWidgetAtPoint method. + */ +core::Widget *Textblock::getWidgetAtPoint(int x, int y, int level) +{ + int lineIndex, wordIndex; + Line *line; + + if (x < allocation.x || + y < allocation.y || + x > allocation.x + allocation.width || + y > allocation.y + getHeight ()) { + return NULL; + } + + lineIndex = findLineIndex (y - allocation.y); + + if (lineIndex < 0 || lineIndex >= lines->size ()) { + return this; + } + + line = lines->getRef (lineIndex); + + for (wordIndex = line->firstWord; wordIndex < line->lastWord; wordIndex++) { + Word *word = words->getRef (wordIndex); + + if (word->content.type == core::Content::WIDGET) { + core::Widget * childAtPoint; + childAtPoint = word->content.widget->getWidgetAtPoint (x, y, + level + 1); + if (childAtPoint) { + return childAtPoint; + } + } + } + + return this; +} + + /** * This function "hands" the last break of a page "over" to a parent * page. This is used for "collapsing spaces". diff --git a/dw/textblock.hh b/dw/textblock.hh --- a/dw/textblock.hh +++ b/dw/textblock.hh @@ -366,6 +366,7 @@ public: void addParbreak (int space, core::style::Style *style); void addLinebreak (core::style::Style *style); + core::Widget *getWidgetAtPoint (int x, int y, int level); void handOverBreak (core::style::Style *style); void changeLinkColor (int link, int newColor); void changeWordStyle (int from, int to, core::style::Style *style, diff --git a/dw/widget.cc b/dw/widget.cc --- a/dw/widget.cc +++ b/dw/widget.cc @@ -676,6 +676,48 @@ Widget *Widget::getNearestCommonAncestor } +/** + * \brief Search recursively through widget. + * + * Used by dw::core::Layout:getWidgetAtPoint. + */ +Widget *Widget::getWidgetAtPoint (int x, int y, int level) +{ + Iterator *it; + Widget *childAtPoint; + + //_MSG ("%*s-> examining the %s %p (%d, %d, %d x (%d + %d))\n", + // 3 * level, "", gtk_type_name (GTK_OBJECT_TYPE (widget)), widget, + // allocation.x, allocation.y, + // allocation.width, allocation.ascent, + // allocation.descent); + + if (x >= allocation.x && + y >= allocation.y && + x <= allocation.x + allocation.width && + y <= allocation.y + getHeight ()) { + //_MSG ("%*s -> inside\n", 3 * level, ""); + /* + * Iterate over the children of this widget. Test recursively, whether + * the point is within the child (or one of its children...). If there + * is such a child, it is returned. Otherwise, this widget is returned. + */ + childAtPoint = NULL; + it = iterator (Content::WIDGET, false); + + while (childAtPoint == NULL && it->next ()) + childAtPoint = it->getContent()->widget->getWidgetAtPoint (x, y, + level + 1); + + if (childAtPoint) + return childAtPoint; + else + return this; + } else + return NULL; +} + + void Widget::scrollTo (HPosition hpos, VPosition vpos, int x, int y, int width, int height) { diff --git a/dw/widget.hh b/dw/widget.hh --- a/dw/widget.hh +++ b/dw/widget.hh @@ -405,6 +405,8 @@ public: inline Layout *getLayout () { return layout; } + virtual Widget *getWidgetAtPoint (int x, int y, int level); + void scrollTo (HPosition hpos, VPosition vpos, int x, int y, int width, int height);

Oct. 19, 2007

./configure confused about FLTK version

by Johannes.Hofmann＠gmx.de

> > Some time ago they were deciding whether {fltk,fltk2}-config. > If you're sure they decided for fltk2-config finally, I'd commit. Currently it's fltk2-config. They might switch back, but I don't think this will happen any time soon. Johannes

Oct. 19, 2007

./configure confused about FLTK version

by bogus＠does.not.exist.com

On Thu, Oct 18, 2007 at 06:29:27PM +0200, Johannes Hofmann wrote: > On Thu, Oct 18, 2007 at 11:46:06AM -0300, Johannes Hofmann wrote: > > On Thu, Oct 18, 2007 at 03:53:25PM +0200, Jan Stary wrote: > > > Hi all, > > > > > > it seems that the ./configure script as generated by ./autogen.sh of > > > current cvs tree will happily go with fltk < 2, giving compilation > > > errors later. > > > > > > Jan > > > > Try this: > > > > - else if sh -c "fltk-config --version" >/dev/null 2>&1 > > + else if sh -c "fltk-config --version|grep ^2" >/dev/null 2>&1 > > All newer fltk2 builds install fltk2-config so I think we could drop the > check for fltk-config alltogether, i.e for dw-testbed: > > diff -r 67316fad7af1 configure.in > --- a/configure.in Thu Oct 18 16:23:15 2007 +0200 > +++ b/configure.in Thu Oct 18 18:27:20 2007 +0200 > @@ -38,14 +38,8 @@ then AC_MSG_RESULT(yes) > LIBFLTK_CXXFLAGS=`fltk2-config --cxxflags` > LIBFLTK_CFLAGS=`fltk2-config --cflags` > LIBFLTK_LIBS=`fltk2-config --use-images --ldflags` > -else if sh -c "fltk-config --version" >/dev/null 2>&1 > - then AC_MSG_RESULT(yes) > - LIBFLTK_CXXFLAGS=`fltk-config --cxxflags` > - LIBFLTK_CFLAGS=`fltk-config --cflags` > - LIBFLTK_LIBS=`fltk-config --ldflags` > - else AC_MSG_RESULT(no) > - AC_ERROR(FLTK2 must be installed!) > - fi > +else AC_MSG_RESULT(no) > + AC_ERROR(FLTK2 must be installed!) > fi Some time ago they were deciding whether {fltk,fltk2}-config. If you're sure they decided for fltk2-config finally, I'd commit. -- Cheers Jorge.-

Oct. 18, 2007

./configure confused about FLTK version

by Johannes.Hofmann＠gmx.de

On Thu, Oct 18, 2007 at 11:46:06AM -0300, Johannes Hofmann wrote: > On Thu, Oct 18, 2007 at 03:53:25PM +0200, Jan Stary wrote: > > Hi all, > > > > it seems that the ./configure script as generated by ./autogen.sh of > > current cvs tree will happily go with fltk < 2, giving compilation > > errors later. > > > > Jan > > Try this: > > - else if sh -c "fltk-config --version" >/dev/null 2>&1 > + else if sh -c "fltk-config --version|grep ^2" >/dev/null 2>&1 All newer fltk2 builds install fltk2-config so I think we could drop the check for fltk-config alltogether, i.e for dw-testbed: diff -r 67316fad7af1 configure.in --- a/configure.in Thu Oct 18 16:23:15 2007 +0200 +++ b/configure.in Thu Oct 18 18:27:20 2007 +0200 @@ -38,14 +38,8 @@ then AC_MSG_RESULT(yes) LIBFLTK_CXXFLAGS=`fltk2-config --cxxflags` LIBFLTK_CFLAGS=`fltk2-config --cflags` LIBFLTK_LIBS=`fltk2-config --use-images --ldflags` -else if sh -c "fltk-config --version" >/dev/null 2>&1 - then AC_MSG_RESULT(yes) - LIBFLTK_CXXFLAGS=`fltk-config --cxxflags` - LIBFLTK_CFLAGS=`fltk-config --cflags` - LIBFLTK_LIBS=`fltk-config --ldflags` - else AC_MSG_RESULT(no) - AC_ERROR(FLTK2 must be installed!) - fi +else AC_MSG_RESULT(no) + AC_ERROR(FLTK2 must be installed!) fi dnl --------------------

Oct. 18, 2007

./configure confused about FLTK version

by bogus＠does.not.exist.com

On Thu, Oct 18, 2007 at 03:53:25PM +0200, Jan Stary wrote: > Hi all, > > it seems that the ./configure script as generated by ./autogen.sh of > current cvs tree will happily go with fltk < 2, giving compilation > errors later. > > Jan Try this: - else if sh -c "fltk-config --version" >/dev/null 2>&1 + else if sh -c "fltk-config --version|grep ^2" >/dev/null 2>&1 -- Cheers Jorge.-

Oct. 18, 2007

directory listings?

by bogus＠does.not.exist.com

Hi, 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). > > Dillo obviously knows the page source, because it shows nonzero bugs in > the bug button, consistently saying ([num of jpegs in the subdirectory] > + 3); for example, clicking on http://stare.cz/~hans/foto/20071010-Barunka > gives > > HTML warning: line 8, <pre> is not allowed to contain <img> > HTML warning: line 9, <pre> is not allowed to contain <hr>. -- closing <pre> > HTML warning: line 10, <pre> is not allowed to contain <img> > HTML warning: line 11, <pre> is not allowed to contain <img> > HTML warning: line 12, <pre> is not allowed to contain <img> > HTML warning: line 13, <pre> is not allowed to contain <img> > > (for other subdirs of http://stare.cz/~hans/foto/ the number > of bug lines just differs by the number of JPEGs); but the content > of the page itself is blank. > > Then again, for some other subdir (which just contains different JPEGs > and has a different name, but is otherwise equivalent), dillo shows the > correct listing (including two spacing "dots" and a "parent directory" > icon, which probably make for the +3 bugs; which is another dillo bug > possibly :-) > > A listing of subdirectory such as http://stare.cz/~hans/foto/20071010-Barunka/ > is always displayed correctly if I just issue > > $ dillo-fltk http://stare.cz/~hans/foto/20071010-Barunka > > on the command line. The above only happens when I _click_ > on a (sub)directory link in a (parent)directory listing. > > Also, listings of _some_ of the subdirectories (if they get listed at > all) jump to the very bottom of the page, as when clicking on > http://stare.cz/~hans/foto/2005-Metheny/ > (obviously, this can only be seen if the directory listing is long enough). > > Again, this never happens when I acccess > the listing directly from commandline. > > Jan > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > This looks like the fourth item in the README file. (Note that some of them are already fixed in CVS). Just try to scroll back. I'll try to fix this annoying bug as soon as I have some time. -- Cheers Jorge.-

Oct. 18, 2007

./configure confused about FLTK version

by hans＠stare.cz

Hi all, it seems that the ./configure script as generated by ./autogen.sh of current cvs tree will happily go with fltk < 2, giving compilation errors later. Jan $ uname -a OpenBSD dell.stare.cz 4.1 GENERIC#0 i386 $ pkg_info | grep fltk fltk-1.1.7 Fast-Light Tool Kit $ pwd /home/hans/src $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dillo2 cvs checkout: Updating dillo2 [...] $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dw2 cvs checkout: Updating dw2 [...] $ ln -s dw2 dw-testbed $ cd dw-testbed $ export AUTOCONF_VERSION=2.61 $ export AUTOMAKE_VERSION=1.9 $ ./autogen.sh aclocal found autoheader found autoconf found automake found [Checks passed] Generating... [...] $ ./configure [...] checking FLTK2... yes [...] config.status: executing depfiles commands $ $ gmake [...] if g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"dw-testbed\" -DVERSION=\"0.0.43j\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_UIO_H=1 -I. -I. -I/usr/local/include -O2 -pipe -I/usr/local/include -I/usr/X11R6/include -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wall -W -Wno-unused-parameter -MT libDw_fltk_a-fltkcomplexbutton.o -MD -MP -MF ".deps/libDw_fltk_a-fltkcomplexbutton.Tpo" -c -o libDw_fltk_a-fltkcomplexbutton.o `test -f 'fltkcomplexbutton.cc' || echo './'`fltkcomplexbutton.cc; \ then mv -f ".deps/libDw_fltk_a-fltkcomplexbutton.Tpo" ".deps/libDw_fltk_a-fltkcomplexbutton.Po"; else rm -f ".deps/libDw_fltk_a-fltkcomplexbutton.Tpo"; exit 1; fi fltkcomplexbutton.cc:23:25: fltk/events.h: No such file or directory fltkcomplexbutton.cc:24:25: fltk/damage.h: No such file or directory fltkcomplexbutton.cc:25:24: fltk/Group.h: No such file or directory fltkcomplexbutton.cc:26:22: fltk/Box.h: No such file or directory In file included from fltkcomplexbutton.cc:29: fltkcomplexbutton.hh:28:24: fltk/Group.h: No such file or directory In file included from fltkcomplexbutton.cc:29: fltkcomplexbutton.hh:34: error: `fltk' is not a class or namespace fltkcomplexbutton.hh:35: error: `Group' is not a class or namespace fltkcomplexbutton.hh:35: error: invalid base-class specification fltkcomplexbutton.hh:43: error: syntax error before `&' token fltkcomplexbutton.hh:45: error: syntax error before `::' token [...]

Oct. 18, 2007

Re: dillo segfaulting

by bogus＠does.not.exist.com

Hi, > - n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp); > + n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp2); > > the problem seems to disappear. Typo! Fixed. -- Cheers Jorge.-

Oct. 18, 2007

small #include glitch on FreeBSD

by bogus＠does.not.exist.com

On Thu, Oct 18, 2007 at 01:32:40PM +0200, Jan Stary wrote: > colors.h:8: error: syntax error before "a_Color_parse" > colors.h:8: error: syntax error before "int32_t" > colors.h:8: warning: type defaults to `int' in declaration of `a_Color_parse' > colors.h:8: warning: data definition has no type or storage class > [...] > > Simply including <sys/types.h> in color.h makes it compile happily. Does it work with <stdint.h> ? -- Cheers Jorge.-

Oct. 18, 2007

directory listings?

by hans＠stare.cz

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). Dillo obviously knows the page source, because it shows nonzero bugs in the bug button, consistently saying ([num of jpegs in the subdirectory] + 3); for example, clicking on http://stare.cz/~hans/foto/20071010-Barunka gives HTML warning: line 8, <pre> is not allowed to contain <img> HTML warning: line 9, <pre> is not allowed to contain <hr>. -- closing <pre> HTML warning: line 10, <pre> is not allowed to contain <img> HTML warning: line 11, <pre> is not allowed to contain <img> HTML warning: line 12, <pre> is not allowed to contain <img> HTML warning: line 13, <pre> is not allowed to contain <img> (for other subdirs of http://stare.cz/~hans/foto/ the number of bug lines just differs by the number of JPEGs); but the content of the page itself is blank. Then again, for some other subdir (which just contains different JPEGs and has a different name, but is otherwise equivalent), dillo shows the correct listing (including two spacing "dots" and a "parent directory" icon, which probably make for the +3 bugs; which is another dillo bug possibly :-) A listing of subdirectory such as http://stare.cz/~hans/foto/20071010-Barunka/ is always displayed correctly if I just issue $ dillo-fltk http://stare.cz/~hans/foto/20071010-Barunka on the command line. The above only happens when I _click_ on a (sub)directory link in a (parent)directory listing. Also, listings of _some_ of the subdirectories (if they get listed at all) jump to the very bottom of the page, as when clicking on http://stare.cz/~hans/foto/2005-Metheny/ (obviously, this can only be seen if the directory listing is long enough). Again, this never happens when I acccess the listing directly from commandline. Jan

Oct. 18, 2007

Re: dillo segfaulting

by hans＠stare.cz

Hi all, > > > > Now it starts, but when i try to load a page it crashes: > > > I think this link may have some clue as to why this occurs: > > > http://sourceware.org/ml/glibc-bugs/2007-08/msg00148.html > > Confirmed, copying the va_list in dStr_vsprintfa (dlib.c) fixes the > > crash for me and i'm now able to display pages. > > Can you make a patch so i can try? that page is too much > technical for my sparse knowledge, i didnt understand anything :) On Oct 05 21:17:47, Vincent Thomasset wrote: > --- dillo-f15.orig/dlib/dlib.c 2007-09-30 23:14:00.000000000 +0200 > +++ dillo-f15/dlib/dlib.c 2007-10-05 21:10:14.000000000 +0200 > @@ -345,8 +345,11 @@ > int n, n_sz; > > if (ds && format) { > + va_list copy; > while (1) { > - n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp); > + va_copy(copy, argp); > + n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, copy); > + va_end(copy); > if (n > -1 && n < ds->sz - ds->len) { > ds->len += n; /* Success! */ > break; > @@ -358,6 +361,7 @@ > dStr_resize(ds, n_sz, (ds->len > 0) ? 1 : 0); > } > } > + > } I am not sure Vincent's diff has been applied correctly to the CVS source. Now dillo2/dlib/dlib.c says void dStr_vsprintfa (Dstr *ds, const char *format, va_list argp) { int n, n_sz; if (ds && format) { va_list argp2; /* Needed in case of looping on non-32bit arch */ while (1) { va_copy(argp2, argp); n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp); va_end(argp2); [...] } I think the point was to feed vsnprintf with the _copy_ (that is, argp2 in this naming); this code does not use the copy in any way (gives the original argp to vsnprintf). When compiled like this, dillo crashes during first few pages. With - n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp); + n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp2); the problem seems to disappear. Jan

Oct. 18, 2007

small #include glitch on FreeBSD

by hans＠stare.cz

Hi all, this is what happens on my FreeBSD 6.2-RELEASE-p8. $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dw2 $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dillo2 $ ln -s dw2 dw-testbed $ cd dw-testbed $ ./autogen.sh && ./configure && make [goes ok] $ cd ../dillo2 $ ./autogen.sh $ ./configure [goes ok] Then make (gmake too) fails with [...] Making all in IO^M if gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' - I/usr/local/include -I../../dw-testbed -I/usr/local/include/libpng -O2 -fno-stri ct-aliasing -pipe -march=pentium3m -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREA D_SAFE -Wall -W -Wno-unused-parameter -Waggregate-return -MT colors.o -MD -MP -M F ".deps/colors.Tpo" -c -o colors.o colors.c; then mv -f ".deps/colors.Tpo" ".d eps/colors.Po"; else rm -f ".deps/colors.Tpo"; exit 1; fi In file included from colors.c:15: colors.h:8: error: syntax error before "a_Color_parse" colors.h:8: error: syntax error before "int32_t" colors.h:8: warning: type defaults to `int' in declaration of `a_Color_parse' colors.h:8: warning: data definition has no type or storage class The colors.h is just --- #ifndef __COLORS_H__ #define __COLORS_H__ #ifdef __cplusplus extern "C" { #endif /* __cplusplus */ int32_t a_Color_parse (const char *subtag, int32_t default_color, int *err); int32_t a_Color_vc(int32_t candidate, int32_t c1, int32_t c2, int32_t c3); #ifdef __cplusplus } #endif /* __cplusplus */ #endif /* __COLORS_H__ */ --- Simply including <sys/types.h> in color.h makes it compile happily. Jan

Oct. 18, 2007

Re: [patch] improve scroll performance of dillo-fltk

by Johannes.Hofmann＠gmx.de

On Sun, Oct 14, 2007 at 04:27:59PM -0300, Johannes Hofmann wrote: > Hi > > On Sun, Oct 14, 2007 at 07:54:23PM +0200, Johannes Hofmann wrote: > > Hi Sebastian, > > > > first of all thanks for your great work! > > > > On Sun, Oct 14, 2007 at 05:55:44PM +0200, Sebastian Geerken wrote: > > > Hi, > > > > > > On Mon, Oct 08, Matthias Franz wrote: > > > > Fine! Only using the arrow keys is quite slow and consumes all CPU time > > > > on my machine. In contrast, srolling with the old Dillo was quick and > > > > produced almost no CPU load. > > > > > > Just to save your time for investigating this further: This is a > > > known problem. Generally, the GTK-based dillo drew only the part of > > > the viewport, which was really needed, e.g. > > > > > > - scrolling was optimized, by copying one part, and redrawing only > > > the formerly invisibly part (IIRC, this was done mostly by > > > GTKLayout), > > > > This is already implemented in dillo-fltk from cvs. > > But gtk1 seems to use an even faster approach. I think they use > > XMoveWindow() instead of XCopyArea() for most part of the window, > > which seems to be faster especially on some older machines. > > You can try FLTK2-r5941 (weekly stable). With that version we > can ask in fltk-dev for details. It's the same with FLTK2-r5941. However what fltk does for scrolling is pretty sensible. We might still switch to a scrolling scheme similar to gtk1 if someone understands what exactly gtk1 is doing and why it is faster. Johannes

Oct. 16, 2007

New CVS repository and patches

by hans＠stare.cz

A few small build questions: > dcvs co dillo2 > dcvs co dw2 OK > cp -r dillo2 dillo2-cur > cp -r dw2 dw2-cur Why do I need to have a complete copy of a directory I just checked out? > ln -s dw2-cur dw-testbed Why do I need another name for that copy? Is it hardwired somewhere? > find dw2-cur -name CVS -exec rm \{\} \; > find dillo2-cur -name CVS -exec rm \{\} \; Why do I need to remove the CVS directories from the source tree? Do they stand in the way of something building properly? Isn't this equiavalent to doing 'cvs export' instead, anyway? > cd dw2-cur > ./autogen.sh > make Do I also need to somehow 'install' this? Because how is the dillo2 src gonna find it otherwise? > cd ../dillo2-cur > ./autogen.sh > make Thanks Jan

Oct. 16, 2007

New CVS repository and patches

by hans＠stare.cz

On Oct 16 18:13:29, Jan Stary wrote: > > > > cvs -z3 -djcid@auriga.wearlab.de:/sfhome/cvs/dillo > > > Great, but it keeps asking for a password, am I missing something? > > Just press ENTER! > > Just asks for password again ... OTOH, -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo works just fine jan

Oct. 16, 2007

New CVS repository and patches

by hans＠stare.cz

> > > cvs -z3 -djcid@auriga.wearlab.de:/sfhome/cvs/dillo > > Great, but it keeps asking for a password, am I missing something? > Just press ENTER! Just asks for password again ... Jan

Oct. 16, 2007

Re: character entity references produce garbage

by matthias.franz＠ujf-grenoble.fr

On Mon, Oct 15, 2007 at 05:58:38PM +0200, Johannes Hofmann wrote: > can you please try the little patch against fltk below. It should > fix the issue with --disable-xft and should not harm in case that > xft is enabled. works! Thanks! -- Matthias Franz

Oct. 15, 2007

Re: character entity references produce garbage

by Johannes.Hofmann＠gmx.de

Hi Matthias, can you please try the little patch against fltk below. It should fix the issue with --disable-xft and should not harm in case that xft is enabled. If it works for you I will send it to the fltk mailling list. Johannes --- src/x11/Font_xlfd.cxx.orig 2007-10-15 17:43:16 +0200 +++ src/x11/Font_xlfd.cxx 2007-10-15 17:43:53 +0200 @@ -432,7 +432,7 @@ void fltk::drawtext_transformed(const ch #if !X_UTF8_FONT XDrawString16(xdisplay, xwindow, gc, int(floorf(x+.5f)), - int(floorf(y+.5f)), buffer, n); + int(floorf(y+.5f)), buffer, count); #else #ifdef FONT_DEBUG //printf("current = %s\n", current->name);

Oct. 15, 2007

Re: [patch] improve scroll performance of dillo-fltk

by bogus＠does.not.exist.com

Hi On Sun, Oct 14, 2007 at 07:54:23PM +0200, Johannes Hofmann wrote: > Hi Sebastian, > > first of all thanks for your great work! > > On Sun, Oct 14, 2007 at 05:55:44PM +0200, Sebastian Geerken wrote: > > Hi, > > > > On Mon, Oct 08, Matthias Franz wrote: > > > Fine! Only using the arrow keys is quite slow and consumes all CPU time > > > on my machine. In contrast, srolling with the old Dillo was quick and > > > produced almost no CPU load. > > > > Just to save your time for investigating this further: This is a > > known problem. Generally, the GTK-based dillo drew only the part of > > the viewport, which was really needed, e.g. > > > > - scrolling was optimized, by copying one part, and redrawing only > > the formerly invisibly part (IIRC, this was done mostly by > > GTKLayout), > > This is already implemented in dillo-fltk from cvs. > But gtk1 seems to use an even faster approach. I think they use > XMoveWindow() instead of XCopyArea() for most part of the window, > which seems to be faster especially on some older machines. You can try FLTK2-r5941 (weekly stable). With that version we can ask in fltk-dev for details. -- Cheers Jorge.-

Oct. 14, 2007

Re: [patch] improve scroll performance of dillo-fltk

by Johannes.Hofmann＠gmx.de

Hi Sebastian, first of all thanks for your great work! On Sun, Oct 14, 2007 at 05:55:44PM +0200, Sebastian Geerken wrote: > Hi, > > On Mon, Oct 08, Matthias Franz wrote: > > Fine! Only using the arrow keys is quite slow and consumes all CPU time > > on my machine. In contrast, srolling with the old Dillo was quick and > > produced almost no CPU load. > > Just to save your time for investigating this further: This is a > known problem. Generally, the GTK-based dillo drew only the part of > the viewport, which was really needed, e.g. > > - scrolling was optimized, by copying one part, and redrawing only > the formerly invisibly part (IIRC, this was done mostly by > GTKLayout), This is already implemented in dillo-fltk from cvs. But gtk1 seems to use an even faster approach. I think they use XMoveWindow() instead of XCopyArea() for most part of the window, which seems to be faster especially on some older machines. Johannes

Oct. 14, 2007

New CVS and newwest FLTK2 release

by bogus＠does.not.exist.com

Hi there, I just updated the CVS so it can use the latest stable FLTK2. Get FLTK2 from www.fltk.org (r5941), or from here: wget http://www.dillo.org/dillo2/fltk-2.0.x-r5941.tar.bz2 You'll have to configure, compile and install this new version, and to rebuild the whole dw2 and dillo2. That way we stay more current. -- Cheers Jorge.-

Oct. 14, 2007

Re: [patch] improve scroll performance of dillo-fltk

by sgeerken＠dillo.org

Hi, On Mon, Oct 08, Matthias Franz wrote: > Fine! Only using the arrow keys is quite slow and consumes all CPU time > on my machine. In contrast, srolling with the old Dillo was quick and > produced almost no CPU load. Just to save your time for investigating this further: This is a known problem. Generally, the GTK-based dillo drew only the part of the viewport, which was really needed, e.g. - scrolling was optimized, by copying one part, and redrawing only the formerly invisibly part (IIRC, this was done mostly by GTKLayout), - small redraw requests (changing the color of a link, drawing one line of an image ...) resulted in drawing of actually small areas, - etc. This is not yet implemented in FLTK, due to the worse support by FLTK, which seems only to support redrawing of whole widgets. (And from the view of FLTK, the viewport is simply one FLTK widget.) For this reason, any redraw request results in redrawing the whole viewport area, which is of course horribly inefficient. In the documentation, there is a list of known problems with FLTK, available at dw-testbed-0.0.47/html/fltk-problems.html (after running doxygen). Anyone, which is a bit familiar with this, is invited to investigate this problem (and the other ones) further. (The "core" of Dw is already prepared, it is just a problem of connecting it to the FLTK-specific code.) When I'm just at it: > A question: Would it be difficult to add mouse wheel support as well? > On my machine that does not work. (Or is thia a configuration issue > regarding FLTK?) Scrolling is completely done by Dw (or, the FLTK part of Dw), so it is, as Johannes already mentioned, missing code. I do not know how scrolling wheel events are handled, but once this problem is solved, it should be simple to add. Sebastian

Oct. 14, 2007

Re: [patch] improve scroll performance of dillo-fltk

by Johannes.Hofmann＠gmx.de

Hi, On Sat, Oct 13, 2007 at 07:58:41PM +0200, Matthias Franz wrote: > Hi, > > I've started comparing the xtraces of dillo1 and dillo2 during scrolling > a long, _empty_ page (just 100 times "<br>"). > > The dillo2 trace contains the request > > 000:<:0392: 28: Request(62): CopyArea src-drawable=0x00a0000a dst-drawable=0x00a0000a gc=0x00a0000b src-x=0 src-y=74 dst-x=0 dst-y=73 width=1009 height=631 > > (A similar line appears in the previous traces of Johannes and mine.) > > For dillo1, I get > > 000:<:05b6: 28: Request(62): CopyArea src-drawable=0x00a00087 dst-drawable=0x00a0006d gc=0x00a00008 src-x=0 src-y=645 dst-x=0 dst-y=645 width=990 height=10 > > I don't have a detailed understanding of what's going on, but I find the > difference in the "height" parameter remarkable. It seems that dillo2 > copies an area - roughly the whole screen - which is 60 (!) times larger > than that copied by dillo1. 60 could also be the performance difference > we observe. That's interesting. dillo2 (with patch) scrolls by copying the screen content that was visible before scrolling and still is after scrolling. So the large CopyArea is expected. Then any freshly exposed area is redrawn from scratch. dillo1 / gtk1 seems to have a more optimized way of doing that, that does not need to copy that much of the screen. There is a link in the gtk code to this document: http://www.gtk.org/~otaylor/whitepapers/guffaw-scrolling.txt which might be related. Cheers, Johannes > > Cheers, > -- > Matthias Franz > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Oct. 14, 2007

Re: [patch] improve scroll performance of dillo-fltk

by matthias.franz＠ujf-grenoble.fr

Hi, I've started comparing the xtraces of dillo1 and dillo2 during scrolling a long, _empty_ page (just 100 times "<br>"). The dillo2 trace contains the request 000:<:0392: 28: Request(62): CopyArea src-drawable=0x00a0000a dst-drawable=0x00a0000a gc=0x00a0000b src-x=0 src-y=74 dst-x=0 dst-y=73 width=1009 height=631 (A similar line appears in the previous traces of Johannes and mine.) For dillo1, I get 000:<:05b6: 28: Request(62): CopyArea src-drawable=0x00a00087 dst-drawable=0x00a0006d gc=0x00a00008 src-x=0 src-y=645 dst-x=0 dst-y=645 width=990 height=10 I don't have a detailed understanding of what's going on, but I find the difference in the "height" parameter remarkable. It seems that dillo2 copies an area - roughly the whole screen - which is 60 (!) times larger than that copied by dillo1. 60 could also be the performance difference we observe. Cheers, -- Matthias Franz

Oct. 13, 2007

Re: [patch] improve scroll performance of dillo-fltk

by bogus＠does.not.exist.com

Hi, > > We should try to get rid of those artefacts for users that can't use > > xft. > > I agree. As Johannes has found out, this is an fltk bug. BTW, we should try FLTK2-r5941 before asking in FLTK-dev. I'll try that one ASAP. -- Cheers Jorge.-

Oct. 13, 2007

Re: [patch] improve scroll performance of dillo-fltk

by bogus＠does.not.exist.com

On Sat, Oct 13, 2007 at 05:04:19PM +0200, Matthias Franz wrote: > On Fri, Oct 12, 2007 at 10:28:38PM +0200, Johannes Hofmann wrote: > > > So could it be that it has to do with RENDER and that most of you > > > have decent hadware acceleration for that? > > > > Yes, I guess that's the reason. You can compile fltk with the > > --disable-xft flag. In this case you will get the artefacts you > > mentioned before, but the performance should be similar to > > dillo1. > > I've compiled fltk with "--disable-xft". Now it doesn't use RENDER > any more (checked with xtrace). But I don't notice any performance > difference to dillo2 with xft. In particular, performance is far > from being that of dillo1. So, xft / RENDER does not seem to be the > reason. Maybe a detailed comparison of the xtrace logs of dillo1 and > dillo2-noxft could help? I've seen that dillo2 uses many "ChangeGC", > "SetClipRectangles" and "PolyFillRectangle" requests, which are not > used by dillo1. I don't know which requests are particularly expensive. AFAIR, dillo2 was passing trough the whole widget tree instead of just the to-be-rendered part. We were testing with Sebastian and optimizations were postponed. I also see a huge difference between dillo1 and dillo2. When Sebastian gets some free time he'll probably comment on that issue. If a simple but long FLTK2 widget can be scrolled with the same technique as in dillo2, with the same performance (or close) to dillo1, we'd know it is a bug within dw2. If not, we may ask in FKTK-dev. BTW, I preferred to take patches for dw2 and to commit them to CVS instead of pushing them for Sebastian to examine. That way he can catch up later while the patches improve. -- Cheers Jorge.-

Oct. 13, 2007

Fwd: Re: [Dillo-dev] New CVS directions page

by bogus＠does.not.exist.com

On Sat, Oct 13, 2007 at 06:40:11PM +0200, Justus Winter wrote: > On Fri, 12 Oct 2007 17:41:41 -0400, dillo-dev-bounces(a)dillo.org wrote: > > Please let me know if this time the directions work! :-P > > I would suggest the following changes: > > - find dw2-cur -name CVS -exec rm \{\} \; > - find dillo2-cur -name CVS -exec rm \{\} \; > + find dw2-cur dillo2-cur -name CVS | xargs rm -R > - cd dw2-cur; ./autogen.sh; ./configure; make > + cd dw2-cur; ./autogen.sh && ./configure && make > cd .. > - cd dillo2-cur; ./autogen.sh; ./configure; make > + cd dillo2-cur; ./autogen.sh && ./configure && make Done. -- Cheers Jorge.-

Oct. 13, 2007

Fwd: Re: [Dillo-dev] New CVS directions page

by 4winter＠informatik.uni-hamburg.de

On Fri, 12 Oct 2007 17:41:41 -0400, dillo-dev-bounces(a)dillo.org wrote: > Please let me know if this time the directions work! :-P I would suggest the following changes: - find dw2-cur -name CVS -exec rm \{\} \; - find dillo2-cur -name CVS -exec rm \{\} \; + find dw2-cur dillo2-cur -name CVS | xargs rm -R - cd dw2-cur; ./autogen.sh; ./configure; make + cd dw2-cur; ./autogen.sh && ./configure && make cd .. - cd dillo2-cur; ./autogen.sh; ./configure; make + cd dillo2-cur; ./autogen.sh && ./configure && make Hummel Hummel, Justus

Oct. 13, 2007