- Dillo-dev - lists.mailman3.com

dillo fltk-1.3 scroll bar delay

by rogerx.oss＠gmail.com

When using the scrollbar to scroll, the scrollbar & page will stop scrolling even though you are still trying to use the scrollbar to move up or down. However, if you use pgdown/pgup... are just click on the bottom or top of the scrollbar, scrolling will proceed page by page without stopping. This bug occurs when the user tries to smooth scroll the page up or down and ceases to exist when moving up or down by page height. I pulled this git yesterday. I'll re-pull/upgrade today sometime. > On Thu, Feb 03, 2011 at 05:49:45AM +0000, corvid wrote: >I'm not too clear on what you might be seeing, but I just pushed >a change that fixes _my_ main problem with the scrollbars, and >maybe they're the same thing. > >There's still the issue that we send events to the scrollbars >when they're hidden. We could check visible(), but perhaps >Johannes would prefer to do some more battle with the resizing >instead. > > >_______________________________________________ >Dillo-dev mailing list >Dillo-dev(a)dillo.org >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 3, 2011

dillo fltk-1.3 scroll bar delay

by johannes.hofmann＠gmx.de

On Thu, Feb 03, 2011 at 01:53:03AM +0000, Roger wrote: > > I messed around with ltrace to debug the scrollbar delay within dillo fltk-1.3 > port. Here's what I get so far. Can you please explain the exact issue you are seeing? Is scrolling generally slow (also with PageDown or drag scrolling), or is it just scrollbar related? For me scrolling is pretty snappy since quite some time now. Cheers, Johannes

Feb. 3, 2011

dillo fltk-1.3 scroll bar delay

by corvid＠lavabit.com

I'm not too clear on what you might be seeing, but I just pushed a change that fixes _my_ main problem with the scrollbars, and maybe they're the same thing. There's still the issue that we send events to the scrollbars when they're hidden. We could check visible(), but perhaps Johannes would prefer to do some more battle with the resizing instead.

Feb. 3, 2011

dillo fltk-1.3 scroll bar delay

by rogerx.oss＠gmail.com

I messed around with ltrace to debug the scrollbar delay within dillo fltk-1.3 port. Here's what I get so far. roger@localhost1 ~ $ ltrace -c -p 11442 % time seconds usecs/call calls function ------ ----------- ----------- --------- -------------------- 18.32 0.291790 6785 43 _ZN8Fl_Group4drawEv 11.69 0.186144 1861 100 _ZN7Fl_Tabs6handleEi 9.70 0.154394 8126 19 _ZN9Fl_Window5flushEv 9.41 0.149853 7887 19 _ZN9Fl_Window4drawEv 9.05 0.144073 7582 19 _ZN7Fl_Tabs4drawEv 8.98 0.142919 793 180 _ZN8Fl_Group6handleEi 6.62 0.105367 115 911 _Znwj 5.82 0.092602 101 911 _ZdlPv 4.82 0.076755 102 746 _ZN2Fl12event_insideEPK9Fl_Widget 2.34 0.037301 153 243 strlen 2.11 0.033615 107 314 malloc 2.06 0.032840 104 314 free 1.81 0.028844 1696 17 _Z9fl_scrolliiiiiiPFvPviiiiES_ 1.49 0.023788 141 168 _ZdaPv 1.11 0.017654 105 168 _Znaj 1.04 0.016517 105 157 __vsnprintf_chk 1.01 0.016079 102 157 _ZN9Fl_Input_5valueEPKc 0.89 0.014229 459 31 _ZN8Fl_Input6handleEi 0.39 0.006271 169 37 _ZNK8Fl_Group10draw_childER9Fl_Widget 0.34 0.005480 103 53 _ZNK8Fl_Group5arrayEv 0.31 0.004997 138 36 _ZNK8Fl_Group12update_childER9Fl_Widget 0.23 0.003682 108 34 _ZN9Fl_Slider11scrollvalueEiiii 0.16 0.002508 192 13 _ZN9Fl_Button4drawEv 0.12 0.001868 116 16 _ZN9Fl_Button6handleEi 0.11 0.001818 106 17 _ZN9Fl_Widget6damageEh 0.02 0.000380 190 2 _ZN6Fl_Box4drawEv 0.02 0.000361 180 2 _ZN8Fl_Input4drawEv 0.01 0.000227 113 2 _ZN9Fl_Window6resizeEiiii ------ ----------- ----------- --------- -------------------- 100.00 1.592356 4729 total roger@localhost1 ~ $ ltrace -c -p 11442 % time seconds usecs/call calls function ------ ----------- ----------- --------- -------------------- 29.26 29.729943 120364 247 _ZN8Fl_Group4drawEv 14.75 14.984334 149843 100 _ZN9Fl_Window5flushEv 14.72 14.952232 149522 100 _ZN9Fl_Window4drawEv 14.69 14.922999 149229 100 _ZN7Fl_Tabs4drawEv 13.48 13.693784 228229 60 _Z9fl_scrolliiiiiiPFvPviiiiES_ 4.09 4.157141 329 12601 strlen 2.28 2.320390 860 2695 _Znwj 2.28 2.317818 860 2695 _ZdlPv 2.15 2.186969 1436 1522 free 0.41 0.421299 141 2982 _ZNK8Fl_Group5arrayEv 0.23 0.238538 126 1884 _ZN2Fl12event_insideEPK9Fl_Widget 0.22 0.220701 147 1500 _ZNK8Fl_Group12update_childER9Fl_Widget 0.19 0.188841 2121 89 _ZN7Fl_Tabs6handleEi 0.18 0.179153 248 720 _ZN8Fl_Group6resizeEiiii 0.18 0.179127 117 1522 malloc 0.16 0.159278 556 286 _ZNK8Fl_Group10draw_childER9Fl_Widget 0.13 0.128988 503 256 _ZN8Fl_Group6handleEi 0.09 0.094990 124 761 __vsnprintf_chk 0.09 0.089326 117 761 _ZN9Fl_Input_5valueEPKc 0.08 0.082873 2762 30 _Z9fl_cursor9Fl_Cursorjj 0.08 0.078284 130 600 _ZN9Fl_Input_6resizeEiiii 0.05 0.048376 115 420 _ZN9Fl_Widget6resizeEiiii 0.04 0.042491 118 360 _Z8fl_widthPKci 0.04 0.036692 136 269 _Znaj 0.03 0.030249 112 269 _ZdaPv 0.02 0.024592 105 233 fl_utf8fwd 0.01 0.013969 194 72 _ZN8Fl_Input4drawEv 0.01 0.013501 112 120 _ZN9Fl_Slider11scrollvalueEiiii 0.01 0.012305 146 84 _ZN8Fl_Input6handleEi 0.01 0.012155 289 42 _ZNK9Fl_Widget10draw_labelEv 0.01 0.007515 121 62 fl_utf8back 0.01 0.007343 174 42 _ZNK9Fl_Widget13draw_backdropEv 0.01 0.006733 112 60 _ZN9Fl_Widget6damageEh 0.00 0.004839 115 42 _ZNK9Fl_Widget8draw_boxE10Fl_Boxtypej 0.00 0.002366 182 13 _ZN9Fl_Button4drawEv 0.00 0.001462 104 14 _ZN6Fl_Box6handleEi 0.00 0.001444 103 14 _ZN9Fl_Button6handleEi 0.00 0.000528 264 2 _ZN6Fl_Box4drawEv 0.00 0.000226 113 2 _ZN9Fl_Window6resizeEiiii ------ ----------- ----------- --------- -------------------- 100.00 101.593794 33631 total

Feb. 3, 2011

Yong Li added you as a business connection on Plaxo

by rogerx.oss＠gmail.com

> On Tue, Feb 01, 2011 at 11:08:29PM -0800, Li Yong wrote: > > Yong Li wants to add you as a business connection on Plaxo. > > To accept this connection request, go to: > [1]http://www.plaxo.com/invite?lang=en&i=120351393&k=1829487072&l=en > > Thanks, > The Plaxo team I feel all cuddly and specially sweet now. ... for a while, thought I might need to go roll myself in powdered sugar. -- Roger http://rogerx.freeshell.org/

Feb. 2, 2011

Yong Li added you as a business connection on Plaxo

by plaxo＠mx.plaxo.com

Yong Li wants to add you as a business connection on Plaxo. To accept this connection request, go to: http://www.plaxo.com/invite?lang=en&i=120351393&k=1829487072&l=en&src=email… Thanks, The Plaxo team Plaxo - your address book for life. Don't want to receive emails from Plaxo any more? Go to: http://www.plaxo.com/stop?src=email&et=1&est=business&etv=jun10d&el=en&emai… Plaxo, Inc. - 203 Ravendale Drive - Mountain View - CA - 94043 - USA

Feb. 2, 2011

patch: configure rm libpng version tests

by weigelt＠metux.de

* Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > > No, upstream should do that (packagers should not have to touch any > > area of the sourcecode). And importing packages should _use_ it. > > (instead of old legacy cruft like the -config scripts or esoteric > > autofool macros). > > You are misunderstanding what I say. Packagers should depend on > pkg-config. If they don't, they are responsible for doing it by hand. To make it a bit more clear: packagers (those folks who create the packages for certain distros) should (be able to) rely on the individual upstreams properly using the pkg-config infrastructure, so they have one common place for doing their necessary adaptions. > > Why should some refuse to install such an fundamental tool ? > > Have you ever looked at the pkg-config source? For something as > fundamental as pkg-config, the source code is a mess. It has a local > copy of at least half of glib1 for example... Yes, I've worked on the codebase. It's not nice, but at least it works (probably better than it will after the already discussed transition to glib2 ;-p). Patches are always welcomed ;-) cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt(a)metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------

Jan. 31, 2011

patch: configure rm libpng version tests

by joerg.sonnenberger＠web.de

On Mon, Jan 31, 2011 at 01:21:36AM +0100, Enrico Weigelt wrote: > * Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > > On Sun, Jan 30, 2011 at 09:47:05PM +0100, Enrico Weigelt wrote: > > > * Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > > > > Pretty much. If you don't have it, you can still override the automatic > > > > detection via PNG_CFLAGS / PNG_LIBS or so. > > > > > > Which requires another special tweak in the distro's package > > > build rules/descriptors - exactly what packagers do not like. > > > > Packagers should provide pkg-config. > > No, upstream should do that (packagers should not have to touch any > area of the sourcecode). And importing packages should _use_ it. > (instead of old legacy cruft like the -config scripts or esoteric > autofool macros). You are misunderstanding what I say. Packagers should depend on pkg-config. If they don't, they are responsible for doing it by hand. > > The only situation in which the manual override is needed if you > > want to build it on a system that doesn't have pkg-config and > > where you don't want to install it. > > Why should some refuse to install such an fundamental tool ? Have you ever looked at the pkg-config source? For something as fundamental as pkg-config, the source code is a mess. It has a local copy of at least half of glib1 for example... Joerg

Jan. 31, 2011

patch: configure rm libpng version tests

by weigelt＠metux.de

* Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > On Sun, Jan 30, 2011 at 09:47:05PM +0100, Enrico Weigelt wrote: > > * Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > > > > > Because most of the original libpng-config is older than the pkgconfig > > > support in libpng :) > > > > Be prepared that it gets dropped some day. (some distros maybe > > already removed it already). And keep in mind that these *-config > > scripts are quite crosscompile-unfriedly. > > Well, as long as upstream installs it... Lets see, how long ... > > > Pretty much. If you don't have it, you can still override the automatic > > > detection via PNG_CFLAGS / PNG_LIBS or so. > > > > Which requires another special tweak in the distro's package > > build rules/descriptors - exactly what packagers do not like. > > Packagers should provide pkg-config. No, upstream should do that (packagers should not have to touch any area of the sourcecode). And importing packages should _use_ it. (instead of old legacy cruft like the -config scripts or esoteric autofool macros). > The only situation in which the manual override is needed if you > want to build it on a system that doesn't have pkg-config and > where you don't want to install it. Why should some refuse to install such an fundamental tool ? cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt(a)metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------

Jan. 31, 2011

patch: configure rm libpng version tests

by joerg.sonnenberger＠web.de

On Sun, Jan 30, 2011 at 09:47:05PM +0100, Enrico Weigelt wrote: > * Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > > > Because most of the original libpng-config is older than the pkgconfig > > support in libpng :) > > Be prepared that it gets dropped some day. (some distros maybe > already removed it already). And keep in mind that these *-config > scripts are quite crosscompile-unfriedly. Well, as long as upstream installs it... > > > Pretty much. If you don't have it, you can still override the automatic > > detection via PNG_CFLAGS / PNG_LIBS or so. > > Which requires another special tweak in the distro's package > build rules/descriptors - exactly what packagers do not like. Packagers should provide pkg-config. The only situation in which the manual override is needed if you want to build it on a system that doesn't have pkg-config and where you don't want to install it. Joerg

Jan. 30, 2011