July 2011 - Dillo-dev - lists.mailman3.com

Benchmark for web page rendering speed; dillo-svn vs dillo 2.2?

by jcid＠dillo.org

On Fri, Jul 08, 2011 at 10:01:09PM +0200, Johannes Hofmann wrote: > On Fri, Jul 08, 2011 at 10:49:33AM -0400, Jimm Katastrophe wrote: > > Could we get a benchmark that compares rendering speeds of web pages, and > > possibly resource usage on top of that as well? I'm just curious to see the > > results :) > > We have http://www.dillo.org/memory.html Yes, I made that table long ago, and although it took some time to make, it proved useful. We'd be grateful if somebody wants to contribute some up-to-date benchmarks. FWIW, I don't know how to add the memory footprint for images stored in the X server (something Firefox seems to do). Rendering speed depends a lot on the HW, making the benchmark in somewhat old and current HW would also be useful. I can't do it now because there's the last dillo-2.x release, and the new dillo-3.0 release pending; which will take most of my time. -- Cheers Jorge.-

July 11, 2011

Tooltips bug

by jcid＠dillo.org

On Sat, Jul 09, 2011 at 03:45:07PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Jul 09, 2011 at 03:31:59AM +0000, corvid wrote: > > > Jorge wrote: > > > > Well, it's really complex and I only got partial workarounds > > > > with Fl_Tooltip (which "fixed" the problem but creating new > > > > ones). > > > > > > > > Finally I went for a custom tooltip implementation. The patches > > > > are commented in the code and in hg (hg log -v). > > > > > > :) > > > > > > Will you use similar code for the UI tooltips, since they're often > > > shown over the rendering area? > > > > Personally I don't see a problem with it... > > If I scroll, they stick to their original spot on the rendering area. Patch committed. -- Cheers Jorge.-

July 10, 2011

Tooltips bug

by jcid＠dillo.org

On Sat, Jul 09, 2011 at 03:45:07PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Jul 09, 2011 at 03:31:59AM +0000, corvid wrote: > > > Jorge wrote: > > > > Well, it's really complex and I only got partial workarounds > > > > with Fl_Tooltip (which "fixed" the problem but creating new > > > > ones). > > > > > > > > Finally I went for a custom tooltip implementation. The patches > > > > are commented in the code and in hg (hg log -v). > > > > > > :) > > > > > > Will you use similar code for the UI tooltips, since they're often > > > shown over the rendering area? > > > > Personally I don't see a problem with it... > > If I scroll, they stick to their original spot on the rendering area. You're right, I never noticed. -- Cheers Jorge.-

July 9, 2011

What's pending in dillo-3.0 for a release

by corvid＠lavabit.com

Jorge wrote: > On Wed, Jun 29, 2011 at 04:29:49PM +0000, corvid wrote: > > > > - KEYS_HIDE_PANELS and KEYS_FULLSCREEN perform the same action. > > OK, this needs a semantic definition. > > I like the way Escape cancels dialogs in dillo, and also during > these months enjoyed Escape hiding panels too. So, more or less, > I'd like to keep it that way. > > Bug: currently Escape hides the findbar only when it has focus. > > I'd remove KEYS_FULLSCREEN, and redefine KEYS_HIDE_PANELS to > close the findbar if it's visible, and all the panels when the > findbar is not visible. > > Comments? My opinion is somewhere between "okay" and "I don't care too much" :) I haven't been able to think of anything else that's wrong with the port...

July 9, 2011

Tooltips bug

by corvid＠lavabit.com

Jorge wrote: > On Sat, Jul 09, 2011 at 03:31:59AM +0000, corvid wrote: > > Jorge wrote: > > > Well, it's really complex and I only got partial workarounds > > > with Fl_Tooltip (which "fixed" the problem but creating new > > > ones). > > > > > > Finally I went for a custom tooltip implementation. The patches > > > are commented in the code and in hg (hg log -v). > > > > :) > > > > Will you use similar code for the UI tooltips, since they're often > > shown over the rendering area? > > Personally I don't see a problem with it... If I scroll, they stick to their original spot on the rendering area.

July 9, 2011

Tooltips bug

by jcid＠dillo.org

On Sat, Jul 09, 2011 at 09:17:51AM -0400, Jorge Arellano Cid wrote: > On Sat, Jul 09, 2011 at 03:31:59AM +0000, corvid wrote: > > Jorge wrote: > > > Well, it's really complex and I only got partial workarounds > > > with Fl_Tooltip (which "fixed" the problem but creating new > > > ones). > > > > > > Finally I went for a custom tooltip implementation. The patches > > > are commented in the code and in hg (hg log -v). > > > > :) > > > > Will you use similar code for the UI tooltips, since they're often > > shown over the rendering area? > > Personally I don't see a problem with it... > > (and it was *much* more work than anticipated, > so I am a bit tired ;) > > > > PS If you're still feeling tooltippishly ambitious, there are the big > > tooltips on lkml.org to do something about... > > Yes, I knew you worked on something like that (and saw an STR). > Now that we have full control over the tooltip, it became quite simple, > just look at this line in fltkplatform.cc: > > ww = 800; // max width; > > That is a suggested max width (i.e. fltk makes it wider when > necessary), but we have full control of the tooltip string in the > constructor, so it can be chopped to fit the desired width. > > BTW, what page are you looking at as test case? Ah, sorry, lkml.org shows the problem. It looks simple as we also control the tooltip placement. -- Cheers Jorge.-

July 9, 2011

Tooltips bug

by jcid＠dillo.org

On Sat, Jul 09, 2011 at 04:30:32AM +0000, corvid wrote: > Jorge wrote: > > Well, it's really complex and I only got partial workarounds > > with Fl_Tooltip (which "fixed" the problem but creating new > > ones). > > > > Finally I went for a custom tooltip implementation. The patches > > are commented in the code and in hg (hg log -v). FWIW, if not clear from the above message: the committed patch solves all the problems seen so far. -- Cheers Jorge.-

July 9, 2011

Tooltips bug

by jcid＠dillo.org

On Sat, Jul 09, 2011 at 03:31:59AM +0000, corvid wrote: > Jorge wrote: > > Well, it's really complex and I only got partial workarounds > > with Fl_Tooltip (which "fixed" the problem but creating new > > ones). > > > > Finally I went for a custom tooltip implementation. The patches > > are commented in the code and in hg (hg log -v). > > :) > > Will you use similar code for the UI tooltips, since they're often > shown over the rendering area? Personally I don't see a problem with it... (and it was *much* more work than anticipated, so I am a bit tired ;) > PS If you're still feeling tooltippishly ambitious, there are the big > tooltips on lkml.org to do something about... Yes, I knew you worked on something like that (and saw an STR). Now that we have full control over the tooltip, it became quite simple, just look at this line in fltkplatform.cc: ww = 800; // max width; That is a suggested max width (i.e. fltk makes it wider when necessary), but we have full control of the tooltip string in the constructor, so it can be chopped to fit the desired width. BTW, what page are you looking at as test case? -- Cheers Jorge.-

July 9, 2011

Tooltips bug

by corvid＠lavabit.com

Jorge wrote: > Well, it's really complex and I only got partial workarounds > with Fl_Tooltip (which "fixed" the problem but creating new > ones). > > Finally I went for a custom tooltip implementation. The patches > are commented in the code and in hg (hg log -v). BTW, it looks like we can rip out the @-escaping again...

July 9, 2011

Tooltips bug

by corvid＠lavabit.com

Jorge wrote: > Well, it's really complex and I only got partial workarounds > with Fl_Tooltip (which "fixed" the problem but creating new > ones). > > Finally I went for a custom tooltip implementation. The patches > are commented in the code and in hg (hg log -v). :) Will you use similar code for the UI tooltips, since they're often shown over the rendering area? PS If you're still feeling tooltippishly ambitious, there are the big tooltips on lkml.org to do something about...

July 9, 2011