- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] [PATCH] version 1 of keyboard navigation patch

by Victor Sahlstedt

On Thu, 16 Oct 2003 13:13:04 +0200 Frank de Lange <frank(a)unternet.org> wrote: > I have not been able to reproduce this yet, will try again and fix > anything I find... But, as stated, it does not happen here... Could have > something to do with your next remark? > > [ LIST: has anyone else seen this? ] No, I can't reproduce this. - Victor

Oct. 16, 2003

Re: [Dillo-dev] [PATCH] version 1 of keyboard navigation patch

by Frank de Lange

Glyn Kennington wrote: > I like most of it. But after a very short time, I've found some things > >that I think need improving. So, in order of decreasing importance: > >1) I've found a bug that will cause dillo to crash: > > Go to a page whose first link is in an alt-tagged image. (The one I've > been using for this bugreport is www.guardian.co.uk .) > > Press the key for `link DOWN'. This will make the image link the > current link (status bar reads "http://www.guardian.co.uk/0,6961,,00.html") > > Go to another page. This can be by clicking Home, Back etc, typing in > another URL, or activating a link on the current page. > > Once dillo is about to start rendering the new page, it dies with a > segfault. gdb tells me that it's at the end of Dw_image_destroy(): > g_free (image->alt_text); > >This crash still occurs if I move to the next link (outside the image) >before going to a different page. > > I have not been able to reproduce this yet, will try again and fix anything I find... But, as stated, it does not happen here... Could have something to do with your next remark? [ LIST: has anyone else seen this? ] >2) Patching problems. I know the email said `use cvs 14/10/2003', but >the patch filename includes the string 20031015, so I attempted to patch >against my just-updated checkout. This normally wouldn't be a problem >over the course of only a day, but today there was some change to the >arguments of a_Commands_set_selection which broke the patch. If you >could include on your webpage the exact date and time of the CVS >checkout, near the link to the patch, it would probably prevent this >sort of confusion from happening again. > > Hmmm... tricky. I'll add a GMT date/time to the CVS version to be used. The date-string on the patch is autogenerated by my patch scripts, it just tells the date I made a release. It is not necessarily related to the CVS date the patch is based on. Sometimes I make incremental changes to a patch without updating CVS. >3) The TODO mentions more bindings. Do you intend to make Back > bindable? > > I intend to make everything bindable. That is, everything which can be bound. That is 'the GTK+ way' of doing things... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 16, 2003

Re: [Dillo-dev] [PATCH] version 11 of tab/frame patch, added keyboard navigation

by Frank de Lange

Stephan Goetter wrote: >Hi, > >I just got this, after opening a new tab, going to >http://www.foobar123.org/ (yes, it doesn't exist :) >and then trying to close the Tab. > >Program received signal SIGSEGV, Segmentation fault. >Menu_pick_url (widget=0x8158e80, client_data=0x8113f20) at menu.c:112 >112 gtk_object_remove_data(GTK_OBJECT (bw->menu_popup.over_image), "url2"); >(gdb) backtrace full >#0 Menu_pick_url (widget=0x8158e80, client_data=0x8113f20) at menu.c:112 > bw = (struct _BrowserWindow *) 0x8113f20 >#1 0x40142ef6 in gtk_marshal_NONE__NONE () from /usr/lib/libgtk-1.2.so.0 >No symbol table info available. >#2 0x40187e16 in gtk_signal_remove_emission_hook () from /usr/lib/libgtk-1.2.so.0 >No symbol table info available. >#3 0x40186f3b in gtk_signal_handlers_destroy () from /usr/lib/libgtk-1.2.so.0 >No symbol table info available. >#4 0x40184b8e in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0 >No symbol table info available. >... > >Greets, >Stephan > > Hmmm, this did not happen here, but that was caused by me using a proxy (privoxy) which produces a nice 'not found' page... Will look in to it asap... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 16, 2003

Re: [Dillo-dev] [PATCH] version 11 of tab/frame patch, added keyboard navigation

by Frank de Lange

johannes leimbach wrote: >Hi! > >You're patch works fine, thanks for the good work. >One (minor) bug though: > >It seems to mess up the tab order of the elements. >Take for example an online forum (phpbb). Go to "Login", so you must >enter an username+password. Before the patch (in 0.7.3) i could set the >focus from textbox 2 textbox with TAB, now it "jump" to a (for me) random >element. > > Yeah, Tab is a bit weird right now. I'll probably bind Tab to gtk_contain_focus (the way it was) in the next version, both for the tab/frame and non-frame version of the patch.. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Oct. 16, 2003

Re: [Dillo-dev] Problem: Dillo not rendering /. correctly

by Ralph Slooten

On Wed, 15 Oct 2003 16:36:17 +0200 johannes leimbach <johannes.leimbach(a)gmx.de> wrote: > Do you have any ideas what might cause this visual annoyance? Yeah, many errors on /.org ... too many. I files a bug report there which just went unnoticed and was marked within 1 day as "closed", even though there was no difference. Due to this problem, and the fact that I love Dillo and slashdot, I created my own site which downloads (using a local cookie) and renders slashdot (front page only) through tidy. If the main page is what you are looking for, you can use my site (works ONLY for Dillo, rejects other browsers totally) at http://slashdot.axljab.homelinux.org/ Greetings Ralph -- http://axljab.homelinux.org/ "...the software said Win95 or better, so I installed Linux"

Oct. 16, 2003

Re: [Dillo-dev] FLTK

by Melvin Hadasht

Hi, > How do I turn off anti-aliasing? I'd like to try it again if you think this > may speed-up redraws. add something like this in your ~/.fonts.conf <match target="font"> <test qual="any" name="size" compare="more"> <int>7</int> </test> <test qual="any" name="size" compare="less"> <int>10</int> </test> <edit name="antialias" mode="assign"> <bool>false</bool> </edit> </match> This will turnoff AA for sizes between 7 and 10 points Cheers -- Melvin Hadasht

Oct. 16, 2003

Re: [Dillo-dev] Re: gtk2 and dillo ( was FLTK )

by Philip Blundell

On Thu, 2003-10-16 at 17:29, Stephen Lewis wrote: > dillo2 > Time to load+render: ~3s > Time to quit: 0.5s (estimated, "felt" slower than dillo1) > Size: 14MB If I recall correctly, there is a bug in the gtk2 patch which causes the text rendering routine to leak large amounts of memory. I have a fix for that somewhere. p.

Oct. 16, 2003

Re: gtk2 and dillo ( was FLTK )

by Stephen Lewis

On Tue, Oct 14, 2003 at 10:20:11AM -0300, Jorge Arellano Cid wrote: > > This is also an RFC for information on GTK+2 (speed, size, > linkings etc). > > Please back your opinions with links, docs, facts or with > whatever helps better to understand the point. Maybe a single > email can show there's no way to do it, or maybe not! I've just been playing with the GTK+2 patch, and I've got some numbers (I won't call them fact :), and opinions: These are on a 500Mhz Intel PC, with 256MB RAM. dillo2 refers to the patched GTK+2 version, dillo1 is GTK1.2 based ( both todays CVS ). The machine is running FreeBSD 5.1 The numbers are basically estimated, but I tried each test several times and got similar results. Test 1: Base load times dillo1 Time to load+render: ~1s Time to quit: instantaneous Size (from top): 7MB dillo2 Time to load+render: ~3s Time to quit: 0.5s (estimated, "felt" slower than dillo1) Size: 14MB Test2: Loading a 1.8MB html file, styled text, bulletted lists, tables of text dillo1 Time to load: 3s extra time to finish rendering: 6s Time to quit: ~2s Size: 56MB dillo2 Time to load: 1m20s real according to the time command, more like 2m30s due to swapping extra time to finish rendering: 10s Time to close: 1m20s Size: 220MB Test3: Loading a trivial 70k html file ( no images or tables, just text in a list ) dillo1 Time to load+render: 1s Time to quit: instantaneous Size: 9MB dillo2 Time to load: 5s Time to render: <1s Time to quit: < 1s Size: 16MB Test4: Loading a 1.5MB html file (fairly simple, no images, few tables) dillo1 Time to load: ~3s extra time to finish rendering: ~6s Time to quit: ~1s Size: 36MB Time to scroll entire length of document by holding pagedown: ~26s dillo2 Time to load: 40s extra time to finish rendering: 2s Time to quit: 16s Size: 125MB Time to scroll entire length of document by holding pagedown: 20s A couple of behavioural notes: 1) Progressive rendering wasn't useful in dillo2, you get an initial draw (which is largely useless), then dillo2 blocks, then the final draw. 2) Scrolling is implemented in quite a different fashion in GTK2 vs GTK1, which has a higher latency, slower "feel". I suspect that GTK+1 would feel as bad using its algorithm if it were using anti-aliased fonts ( opinion based on little evidence ) This isn't really a problem for sequential scrolling, but random seeking by dragging the scrollbar is very irritating under GTK+2 I think this is due to changes relating to the "draw" signal, mentioned in the GTK1.2-2.0 changelog: ... GTK+ merges all invalid regions, and sends expose events to the widget in an idle handler for the invalid regions. ... The things that I found pretty much unusable were - load times ( for anything non-trivial ) - close times ( for large documents ) - memory usage If it's not possible to mitigate these in a GTK+2 version of dillo, then I personally wouldn't find it to be a usable choice anymore (which would suck - I like dillo). On the other hand, if those numbers could be brought down to even, say, twice what dillo1 requires, I think it would be fine (at least, on my hardware). -- Stephen Lewis

Oct. 16, 2003

Re: [Dillo-dev] FLTK

by Sebastian Geerken

On Wed, Oct 15, Stephan Goetter wrote: > gtk-gnutella (http://gtk-gnutella.sf.net/) has similar performance > problems with GTK2. There is a comment about a 1 Ghz PC.. > > Currently they do it like this way. > > #ifndef USE_GTK2 > #define g_ascii_strcasecmp g_strcasecmp > #define gdk_drawable_get_size gdk_window_get_size > #endif > > Don't know if this is an option for dillo (recent talks) and > what is left in the gtk2-patch after using such macros. No, there are much more dependencies, to GtkObject/GObject, to the GtkLayout widget, and to Pango, about which we actually hoped, that it may help us to solve many M17n problems. Sebastian

Oct. 15, 2003

Re: [Dillo-dev] FLTK

by Sebastian Geerken

Hi Eric! Only some remarks about my experiences. I'm only using Gtk 2.0 and Pango 1.0, I'll update to see if it makes a difference. Startup time is a bit difficult to measure, since the disk cache state etc. may influence this. What I found out: - Dillo1 uses libraries which take 4351.38 KB of disk space, while the libs dillo2 uses take 6714.99. For this, I've simpy added the sizes of the files from the output of "ldd". - After having already started both versions, and measured the startup time (with a non-existing file, so that no rendering time can be assumed), dillo2 uses a bit more time (0.11 secs, as opposed to 0.08 secs on my rather new box), which may be due to an increased time for initialization. I've found no difference in drawing time, but this has only played a bit time in dillo1 (at least for text). I've not configured anything for Pango, and from what I see on the screen, anti-aliasing (which may take much time) is turned off. What *does* take far more time is the initial rendering, while rewrapping is exactly as fast as before. This (and also that Pango is only used for drawing, and determing the size of fonts and words) lets me assume that Dw_page_shape_glyphs is not very efficient. I've tried to track down this with gprof, but somehow the profile does not give me much clues. Perhaps it is worth to optimize this code. (The comparison is a bit unfair because of the different grades of matureness :-) Sebastian PS: Like Jorge, I read the list, too :-)

Oct. 15, 2003