- Dillo-dev - lists.mailman3.com

patch: scroll upon resize

by jcid＠dillo.org

On Mon, Sep 15, 2008 at 05:20:01PM +0200, Johannes Hofmann wrote: > Hi, > > On Mon, Sep 15, 2008 at 02:57:27AM +0000, corvid wrote: > > You know how > > - you are scrolled down or to the right > > - you make the viewport larger > > - the scrollbar disappears > > - you can only get the rest of the document back by hitting some > > arrow keys or something > > Yes, I know... > > > > > This seems to fix it, although my usual dw disclaimer applies: > > I don't know whether this is necessarily the right place for > > the change. > > I was thinking about something like this before. > The only problem I see is with tiling window managers like e.g. dwm: > With these windows often get resized, then resized back to their old > size. Currently such a resize cycle does not change the scrolling > position, which is quite nice. > But as most people use ordinary window managers, I'd say we should > commit this fix. Committed. > Perhaps we will find something later that also > keeps the scrolling position after resizing back to the original > size. ACK. > > > > > PS When making the viewport very narrow and then maximizing, I notice > > that the location bar does not go back to showing the whole address. > > I don't know whether that's dillo's fault or fltk's fault. > > > > PPS Amazing how much code we need for dealing with scrolling and scrollbars... > > Yes, that's true. Quite a lot of code actually handles hiding and > showing of the scrollbars and their influence on the size of the viewable > area. > I had proposed a quite radical patch some time ago that moved the > scrollbars from the viewport to the gui (and thereby from dw2 to > dillo2). > This would eliminate all scrollbar related code from dw2. > However as I'm not confident enough that I did not miss any subtle > effects and the current code works fine I would keep things as they > are for the release. > I can update my patch and put it up for discussion after the > release. Yes, it would be good to reconsider it. AFAIR the main reasons it wan't committed were the author wasn't 100% confident, and we were expecting some comments. It can be re-considered after the release. -- Cheers Jorge.-

Sept. 17, 2008

[patch] switch to standard assert

by jcid＠dillo.org

On Wed, Sep 17, 2008 at 05:11:08PM +0200, Johannes Hofmann wrote: > On Tue, Sep 16, 2008 at 09:21:45PM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Sep 16, 2008 at 07:20:31PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Tue, Sep 16, 2008 at 05:41:04PM +0000, corvid wrote: > > > > > > Turning off bounds checking for get and getRef does get rid of nearly > > > > > > all of the assert()s, but I was just trying -Winline and discovered: > > > > > > > > > > > > ./lout/misc.hh: In function 'void lout::misc::assert(bool, const char*, ...)': > > > > > > ./lout/misc.hh:36: warning: function 'void lout::misc::assert(bool, const char* > > > > > > , ...)' can never be inlined because it uses variable argument lists > > > > > > .. > > > > > > > > > > Ouch. A short grep shows that variable argument lists are not used > > > > > (yet) in the code - just const strings. > > > > > So we could change assert to use a const char* argument if I'm not > > > > > missing something. > > > > > > > > For me, grep shows > > > > layout.cc: misc::assert (anchor, "anchor '%s' not defined", name); > > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > > > > > > > Must have missed these... > > > In that case we could get away with something as in attached patch, > > > but we should also consider to just switch to standard assert(). > > > At the moment I would actually prefer the latter. > > > What do others think? > > > > Standard assert() sounds fine to me. > > > > Ok. Here comes the patch. > It also adds a missing check for negative values in SimpleVector > methods. Does this patch show any performance improvement? If it does and has no portability problems, I'm for it too. -- Cheers Jorge.-

Sept. 17, 2008

[patch] switch to standard assert

by Johannes.Hofmann＠gmx.de

On Tue, Sep 16, 2008 at 09:21:45PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Sep 16, 2008 at 07:20:31PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Tue, Sep 16, 2008 at 05:41:04PM +0000, corvid wrote: > > > > > Turning off bounds checking for get and getRef does get rid of nearly > > > > > all of the assert()s, but I was just trying -Winline and discovered: > > > > > > > > > > ./lout/misc.hh: In function 'void lout::misc::assert(bool, const char*, ...)': > > > > > ./lout/misc.hh:36: warning: function 'void lout::misc::assert(bool, const char* > > > > > , ...)' can never be inlined because it uses variable argument lists > > > > > .. > > > > > > > > Ouch. A short grep shows that variable argument lists are not used > > > > (yet) in the code - just const strings. > > > > So we could change assert to use a const char* argument if I'm not > > > > missing something. > > > > > > For me, grep shows > > > layout.cc: misc::assert (anchor, "anchor '%s' not defined", name); > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > > > > Must have missed these... > > In that case we could get away with something as in attached patch, > > but we should also consider to just switch to standard assert(). > > At the moment I would actually prefer the latter. > > What do others think? > > Standard assert() sounds fine to me. > Ok. Here comes the patch. It also adds a missing check for negative values in SimpleVector methods. Cheers, Johannes

Sept. 17, 2008

8.68% of my time in assert()?

by corvid＠lavabit.com

Johannes wrote: > On Tue, Sep 16, 2008 at 07:20:31PM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Sep 16, 2008 at 05:41:04PM +0000, corvid wrote: > > > > Turning off bounds checking for get and getRef does get rid of nearly > > > > all of the assert()s, but I was just trying -Winline and discovered: > > > > > > > > ./lout/misc.hh: In function 'void lout::misc::assert(bool, const char*, ...)': > > > > ./lout/misc.hh:36: warning: function 'void lout::misc::assert(bool, const char* > > > > , ...)' can never be inlined because it uses variable argument lists > > > > .. > > > > > > Ouch. A short grep shows that variable argument lists are not used > > > (yet) in the code - just const strings. > > > So we could change assert to use a const char* argument if I'm not > > > missing something. > > > > For me, grep shows > > layout.cc: misc::assert (anchor, "anchor '%s' not defined", name); > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > > > > Must have missed these... > In that case we could get away with something as in attached patch, > but we should also consider to just switch to standard assert(). > At the moment I would actually prefer the latter. > What do others think? Standard assert() sounds fine to me.

Sept. 16, 2008

8.68% of my time in assert()?

by Johannes.Hofmann＠gmx.de

On Tue, Sep 16, 2008 at 07:20:31PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Sep 16, 2008 at 05:41:04PM +0000, corvid wrote: > > > Turning off bounds checking for get and getRef does get rid of nearly > > > all of the assert()s, but I was just trying -Winline and discovered: > > > > > > ./lout/misc.hh: In function 'void lout::misc::assert(bool, const char*, ...)': > > > ./lout/misc.hh:36: warning: function 'void lout::misc::assert(bool, const char* > > > , ...)' can never be inlined because it uses variable argument lists > > > .. > > > > Ouch. A short grep shows that variable argument lists are not used > > (yet) in the code - just const strings. > > So we could change assert to use a const char* argument if I'm not > > missing something. > > For me, grep shows > layout.cc: misc::assert (anchor, "anchor '%s' not defined", name); > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", > Must have missed these... In that case we could get away with something as in attached patch, but we should also consider to just switch to standard assert(). At the moment I would actually prefer the latter. What do others think? Cheers, Johannes PS: I don't see any speed difference with attached patch when loading the huge mysql manual page.

Sept. 16, 2008

8.68% of my time in assert()?

by corvid＠lavabit.com

Johannes wrote: > On Tue, Sep 16, 2008 at 05:41:04PM +0000, corvid wrote: > > Turning off bounds checking for get and getRef does get rid of nearly > > all of the assert()s, but I was just trying -Winline and discovered: > > > > ./lout/misc.hh: In function 'void lout::misc::assert(bool, const char*, ...)': > > ./lout/misc.hh:36: warning: function 'void lout::misc::assert(bool, const char* > > , ...)' can never be inlined because it uses variable argument lists > > .. > > Ouch. A short grep shows that variable argument lists are not used > (yet) in the code - just const strings. > So we could change assert to use a const char* argument if I'm not > missing something. For me, grep shows layout.cc: misc::assert (anchor, "anchor '%s' not defined", name); misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d", misc.hh: assert (i < this->num, "Array index out of bounds: %d >= %d",

Sept. 16, 2008

8.68% of my time in assert()?

by Johannes.Hofmann＠gmx.de

On Tue, Sep 16, 2008 at 05:41:04PM +0000, corvid wrote: > Turning off bounds checking for get and getRef does get rid of nearly > all of the assert()s, but I was just trying -Winline and discovered: > > ./lout/misc.hh: In function 'void lout::misc::assert(bool, const char*, ...)': > ./lout/misc.hh:36: warning: function 'void lout::misc::assert(bool, const char* > , ...)' can never be inlined because it uses variable argument lists > .. Ouch. A short grep shows that variable argument lists are not used (yet) in the code - just const strings. So we could change assert to use a const char* argument if I'm not missing something. > > Earlier I'd said assert() was not cheap, but I was still uncertain about > how -g and -pg might be affecting inlining. Now I _know_ that assert() is > not cheap. > Nice catch! Johannes

Sept. 16, 2008

8.68% of my time in assert()?

by corvid＠lavabit.com

Turning off bounds checking for get and getRef does get rid of nearly all of the assert()s, but I was just trying -Winline and discovered: ./lout/misc.hh: In function 'void lout::misc::assert(bool, const char*, ...)': ./lout/misc.hh:36: warning: function 'void lout::misc::assert(bool, const char* , ...)' can never be inlined because it uses variable argument lists .. Earlier I'd said assert() was not cheap, but I was still uncertain about how -g and -pg might be affecting inlining. Now I _know_ that assert() is not cheap.

Sept. 16, 2008

load_images and multiple windows

by Johannes.Hofmann＠gmx.de

On Tue, Sep 16, 2008 at 12:10:15AM +0000, corvid wrote: > Jorge wrote: > > On Sat, Sep 06, 2008 at 09:00:33PM +0200, Johannes Hofmann wrote: > > > Should load_images be a per window variable, or should we update the > > > buttons in all other windows? > > > > A per window setting looks OK to me. That way people that use > > it only on certain pages (like me) are happy, and those that prefer > > text mode most of the time can have load_images=NO in dillo2rc. > > I just put this together. I won't make much use of it, so please test. > Nice! It even simplifies things a bit. Thanks, Johannes

Sept. 16, 2008

load_images and multiple windows

by corvid＠lavabit.com

Jorge wrote: > On Sat, Sep 06, 2008 at 09:00:33PM +0200, Johannes Hofmann wrote: > > Should load_images be a per window variable, or should we update the > > buttons in all other windows? > > A per window setting looks OK to me. That way people that use > it only on certain pages (like me) are happy, and those that prefer > text mode most of the time can have load_images=NO in dillo2rc. I just put this together. I won't make much use of it, so please test.

Sept. 16, 2008