- Dillo-dev - lists.mailman3.com

[experimental patch] excessive redraws (again)

by jcid＠dillo.org

Hi Johannes, > > > [...] > > > * Of course we still should reconsider each call to queueDrawTotal() > > > or queueResize() and verify whether it is really necessary. > > > However I think we should favor correctness over speed. That > > > means, whenever the layout might have changed, we must call > > > queueResize(). > > > > Sure. The patch is not complete. After adding the missing > > flushes it should work OK. And refresh_delay would help to set > > the desired behaviour. I just committed some missing flushes so now the code updates the screen ASAP when finishing a bare image URL, a plain text page, and after the viewport resizes. Basically it behaves as "update on finish" (except that images still queue a drawTotal so they update the whole canvas while loading). Adding a tiemout to update periodically is easy, and thus the model would be more or less complete. Although it's simple (I've done it in my tree for testing), the CVS "as is" is the best to spot the bugs. I'll keep on reviewing and expecting your work&comments. -- Cheers Jorge.-

Feb. 8, 2008

Dillo screenshot on my ipaq

by akemnade＠tzi.de

Hi, I have finally taken the time to make dillo run on my ipaq. Screenshot: http://www.tzi.de/~akemnade/dillo-ipaq.png The big pitfall here is if you don't enable Xft/freetype in your fltk build, you can screw up things. fltk does not get the default fonts from the xserver on the ipaq, so due to missing error checking in fltk, dillo crashes when the first label gets rendered. But I guess, without freetype you won't get nice fonts anyway... dillo/dw does not need to be patched for that. fltk needs a bit of tweaking, I'll look if it is solved in the current version (I'm still using that r5917 snapshot). Greetings Andreas Kemnade

Feb. 8, 2008

[experimental patch] excessive redraws (again)

by jcid＠dillo.org

On Thu, Feb 07, 2008 at 11:45:18PM -0300, Jorge Arellano Cid wrote: > Hi, > > > > [...] > > > Back in 2005 we needed to test the prototype quickly, so it was > > > reasonable to simply add, for instance, a queuedrawTotal() call > > > when only a queuedraw() was needed and to postpone clipping until > > > the basics were working. > > > > > > I believe this is what is asking for a review now. > > > > Yes sure. There might be places where we can replace the > > queueDrawTotal(). Let's go through the code with this in mind. > > Funny how commenting out Widget::queueDrawArea() gives the same > rendering (note that Widget::queueDraw() calls Widget::queueDrawArea()). > > When there are images a number in the hundred magnitude may be wasted. > > :-) Well, actually is not exactly the same. Looks the same when the image is local, and doesn't render incrementaly over slow connections. -- Cheers Jorge.-

Feb. 8, 2008

[experimental patch] excessive redraws (again)

by jcid＠dillo.org

Hi, > > [...] > > Back in 2005 we needed to test the prototype quickly, so it was > > reasonable to simply add, for instance, a queuedrawTotal() call > > when only a queuedraw() was needed and to postpone clipping until > > the basics were working. > > > > I believe this is what is asking for a review now. > > Yes sure. There might be places where we can replace the > queueDrawTotal(). Let's go through the code with this in mind. Funny how commenting out Widget::queueDrawArea() gives the same rendering (note that Widget::queueDraw() calls Widget::queueDrawArea()). When there are images a number in the hundred magnitude may be wasted. :-) -- Cheers Jorge.-

Feb. 8, 2008

[experimental patch] excessive redraws (again)

by jcid＠dillo.org

On Thu, Feb 07, 2008 at 09:50:00PM +0100, Johannes Hofmann wrote: > Hi, > > On Thu, Feb 07, 2008 at 05:23:40PM -0300, Jorge Arellano Cid wrote: > > - snip - > > > > > > > If I understand this correctly, the patch now is equivalent to > > > removing the calls to queueDrawTotal(), where asap == false, right? > > > > Right. > > > > But the idea is to queue when asap == false, and to set a delayed > > draw that is user adjustable in seconds (e.g. 0, 0.5, 1, 3, ...). > > Ok. I think we mostly agree on what needs to be done. My only > concern with your aproach is that I wonder why the new asap > parameter is needed: > When to call with asap == true and when to call it with asap == false? As a synonym for flush. For instance when and image finishes loading we can call with asap=true and if we want it to display incrementally, we can asap=true every update. asap=false can mean: "this operation is needed but can be delayed". > > > * Frequent redraws are good if they update the visible content. > > > E.g. when loading a page over a slow line. > > > Immediate feedback to the user is a great feature of dillo. > > > The screen flickering can be avoided with some double buffer > > > mechanism. > > > > Choosing refresh_delay=0 would give immediate feedback. > > > > refresh_delay=3 could yield low CPU usage and very good > > performance. > > Yes, that's exactly what my patch does. It delays the actual > drawing operation if there is other things to do (e.g. new data is > coming in). Yes, both patches attack the same problem after all. Once the code is cleaned, we can choose the one that fits better. I liked the flush/asap approach because it was putting unnecesary calls under the spotlight. It was also faster in some tests. Although this may change after the cleanup. > > > [...] > > > * It would be nice, if we could decide whether a resizing widget > > > affects the layout that is currently visible, so that we could > > > avoid redrawing in this case. This would avoid redrawing when > > > loading very long pages as the DragonFly package list. > > > But I don't think this is easy. > > > > Back in 2005 we needed to test the prototype quickly, so it was > > reasonable to simply add, for instance, a queuedrawTotal() call > > when only a queuedraw() was needed and to postpone clipping until > > the basics were working. > > > > I believe this is what is asking for a review now. > > Yes sure. There might be places where we can replace the > queueDrawTotal(). Let's go through the code with this in mind. OK. I also have yet to understand how it all fits together... (allocate/resize/draw) > > > Also we should agree on what we actually want to optimize. > > > I don't think CPU usage or number of redraws are enough. > > > Instead dillo should be usable and "feel fast" on fast and > > > slow or loaded systems (if CPU is available, why not use it?). > > > > I believe we can have it all! (as explained above). > > Same here :-) Good. -- Cheers Jorge.-

Feb. 7, 2008

[experimental patch] excessive redraws (again)

by Johannes.Hofmann＠gmx.de

Hi, On Thu, Feb 07, 2008 at 05:23:40PM -0300, Jorge Arellano Cid wrote: - snip - > > > > If I understand this correctly, the patch now is equivalent to > > removing the calls to queueDrawTotal(), where asap == false, right? > > Right. > > But the idea is to queue when asap == false, and to set a delayed > draw that is user adjustable in seconds (e.g. 0, 0.5, 1, 3, ...). Ok. I think we mostly agree on what needs to be done. My only concern with your aproach is that I wonder why the new asap parameter is needed: When to call with asap == true and when to call it with asap == false? > > > With this patch I see missing screen updates e.g. when resizing the > > window. > > Yes some glitches remain. There's still a need to add a few > queueDrawTotal(true) calls in necessary places so this is solved. > Once this is done, the amount of CPU usage decreases dramatically > and the user can choose a refresh rate. > > > First let me explain how I think the drawing and relayout is > > designed in dillo2. Please correct me if I'm wrong. > > Oh, I didn't design it so we're both exploring this area. > > > > * Frequent redraws are good if they update the visible content. > > E.g. when loading a page over a slow line. > > Immediate feedback to the user is a great feature of dillo. > > The screen flickering can be avoided with some double buffer > > mechanism. > > Choosing refresh_delay=0 would give immediate feedback. > > refresh_delay=3 could yield low CPU usage and very good > performance. Yes, that's exactly what my patch does. It delays the actual drawing operation if there is other things to do (e.g. new data is coming in). > > e.g. as place commented: > > > > You can try with the new patch. > > > > dillo-fltk immediate /* clear_double_buffer(); */ > > dillo-fltk 0:06 clear_double_buffer(); > > > > * queueResize() calls are put into the code whenever the layout > > might have changed without worrying too much about performance. > > To make this efficient, queueResize() or queueDrawTotal() just > > remembers drawing or resizing should be done at some time in > > the future. > > It looks like, but there are also some unimplemented functions > like startDrawing (), finishDrawing(), and flush(). Maybe they > were discarded, myabe left for future implementation, or left for > a second design-pass. > > > > * The idle function mechanism then does the actual work of resizing > > or redrawing. This way many calls to queueResize() can cause many > > resize operations, or they can be combined to just single resize > > depending on when the idle functions are called. > > When loading the same page, dillo can update the screen frequently > > if enough CPU is available, or less often, if CPU time is not > > available. > > > > I think this is an excellent concept :-) > > :) > > > > So what do we need to do? > > > > * Make the concept work properly. Here I think we need to improve > > the code where the idle functions are called so that multiple > > redraws are really combined especially if there is no CPU available. > > > > * Of course we still should reconsider each call to queueDrawTotal() > > or queueResize() and verify whether it is really necessary. > > However I think we should favor correctness over speed. That > > means, whenever the layout might have changed, we must call > > queueResize(). > > Sure. The patch is not complete. After adding the missing > flushes it should work OK. And refresh_delay would help to set > the desired behaviour. > > > * It would be nice, if we could decide whether a resizing widget > > affects the layout that is currently visible, so that we could > > avoid redrawing in this case. This would avoid redrawing when > > loading very long pages as the DragonFly package list. > > But I don't think this is easy. > > Back in 2005 we needed to test the prototype quickly, so it was > reasonable to simply add, for instance, a queuedrawTotal() call > when only a queuedraw() was needed and to postpone clipping until > the basics were working. > > I believe this is what is asking for a review now. Yes sure. There might be places where we can replace the queueDrawTotal(). Let's go through the code with this in mind. > > > Also we should agree on what we actually want to optimize. > > I don't think CPU usage or number of redraws are enough. > > Instead dillo should be usable and "feel fast" on fast and > > slow or loaded systems (if CPU is available, why not use it?). > > I believe we can have it all! (as explained above). Same here :-) Cheers, Johannes

Feb. 7, 2008

[experimental patch] excessive redraws (again)

by jcid＠dillo.org

Hi, On Wed, Feb 06, 2008 at 01:13:30PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Mon, Feb 04, 2008 at 07:31:29PM -0300, Jorge Arellano Cid wrote: > > > > Well an experimental prototype was committed. > > The original idea here was to use this new API: > > > > void Textblock::flush (bool asap) > > void FltkViewBase::queueDrawTotal (bool asap) > > > > (asap = "As soon as possible") > > > > and to call the function inmediately when "asap" is true and to > > otherwise delay to a tunable number of seconds. > > > > After some tests it showed extraordinarily effective. For instance > > testing with the "All" directory from: > > > > http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10.… > > > > it was roughly using 2 to 3 times less CPU (in my notebook) than > > using the FltkPlatform::generalIdle() throttling patch. > > > > Some glitches remained, and while I was working on it, the test > > server above went down... :( > > > > I got a big surprise when after some more tests, it worked quite well > > when ignoring everything but calls with asap=true ! :-) > > > > For instance, now the code reads: > > > > void FltkViewBase::queueDrawTotal (bool asap) > > { > > static time_t lastRedraw = 0; > > > > //if (asap || time(0) > lastRedraw + 2) { > > if (asap) { > > redraw (DAMAGE_EXPOSE); > > lastRedraw = time(0); > > } > > } > > If I understand this correctly, the patch now is equivalent to > removing the calls to queueDrawTotal(), where asap == false, right? Right. But the idea is to queue when asap == false, and to set a delayed draw that is user adjustable in seconds (e.g. 0, 0.5, 1, 3, ...). > With this patch I see missing screen updates e.g. when resizing the > window. Yes some glitches remain. There's still a need to add a few queueDrawTotal(true) calls in necessary places so this is solved. Once this is done, the amount of CPU usage decreases dramatically and the user can choose a refresh rate. > First let me explain how I think the drawing and relayout is > designed in dillo2. Please correct me if I'm wrong. Oh, I didn't design it so we're both exploring this area. > * Frequent redraws are good if they update the visible content. > E.g. when loading a page over a slow line. > Immediate feedback to the user is a great feature of dillo. > The screen flickering can be avoided with some double buffer > mechanism. Choosing refresh_delay=0 would give immediate feedback. refresh_delay=3 could yield low CPU usage and very good performance. e.g. as place commented: > > You can try with the new patch. > > dillo-fltk immediate /* clear_double_buffer(); */ > dillo-fltk 0:06 clear_double_buffer(); > * queueResize() calls are put into the code whenever the layout > might have changed without worrying too much about performance. > To make this efficient, queueResize() or queueDrawTotal() just > remembers drawing or resizing should be done at some time in > the future. It looks like, but there are also some unimplemented functions like startDrawing (), finishDrawing(), and flush(). Maybe they were discarded, myabe left for future implementation, or left for a second design-pass. > * The idle function mechanism then does the actual work of resizing > or redrawing. This way many calls to queueResize() can cause many > resize operations, or they can be combined to just single resize > depending on when the idle functions are called. > When loading the same page, dillo can update the screen frequently > if enough CPU is available, or less often, if CPU time is not > available. > > I think this is an excellent concept :-) :) > So what do we need to do? > > * Make the concept work properly. Here I think we need to improve > the code where the idle functions are called so that multiple > redraws are really combined especially if there is no CPU available. > > * Of course we still should reconsider each call to queueDrawTotal() > or queueResize() and verify whether it is really necessary. > However I think we should favor correctness over speed. That > means, whenever the layout might have changed, we must call > queueResize(). Sure. The patch is not complete. After adding the missing flushes it should work OK. And refresh_delay would help to set the desired behaviour. > * It would be nice, if we could decide whether a resizing widget > affects the layout that is currently visible, so that we could > avoid redrawing in this case. This would avoid redrawing when > loading very long pages as the DragonFly package list. > But I don't think this is easy. Back in 2005 we needed to test the prototype quickly, so it was reasonable to simply add, for instance, a queuedrawTotal() call when only a queuedraw() was needed and to postpone clipping until the basics were working. I believe this is what is asking for a review now. > Also we should agree on what we actually want to optimize. > I don't think CPU usage or number of redraws are enough. > Instead dillo should be usable and "feel fast" on fast and > slow or loaded systems (if CPU is available, why not use it?). I believe we can have it all! (as explained above). -- Cheers Jorge.-

Feb. 7, 2008

[patch] fix HomeKey/EndKey behaviour

by jcid＠dillo.org

On Wed, Feb 06, 2008 at 06:21:23PM +0100, Johannes Hofmann wrote: > Hi > > the patch below makes HomeKey and EndKey work as it did in dillo1. > I think I had introduced the current behaviour that also adjusts the > x-position but it is pretty annoying on wide pages. Committed. -- Cheers Jorge.-

Feb. 7, 2008

[patch] fix HomeKey/EndKey behaviour

by Johannes.Hofmann＠gmx.de

Hi the patch below makes HomeKey and EndKey work as it did in dillo1. I think I had introduced the current behaviour that also adjusts the x-position but it is pretty annoying on wide pages. Cheers, Johannes diff -r 1c41f9a73971 dw/fltkviewport.cc --- a/dw/fltkviewport.cc Sun Feb 03 21:13:11 2008 +0100 +++ b/dw/fltkviewport.cc Wed Feb 06 18:16:41 2008 +0100 @@ -292,11 +292,11 @@ int FltkViewport::handle (int event) return 1; case HomeKey: - scrollTo (0, 0); + scrollTo (scrollX, 0); return 1; case EndKey: - scrollTo (canvasWidth, canvasHeight); /* gets adjusted in scroll() */ + scrollTo (scrollX, canvasHeight); /* gets adjusted in scroll() */ return 1; } }

Feb. 6, 2008

[experimental patch] excessive redraws (again)

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Mon, Feb 04, 2008 at 07:31:29PM -0300, Jorge Arellano Cid wrote: > > Well an experimental prototype was committed. > The original idea here was to use this new API: > > void Textblock::flush (bool asap) > void FltkViewBase::queueDrawTotal (bool asap) > > (asap = "As soon as possible") > > and to call the function inmediately when "asap" is true and to > otherwise delay to a tunable number of seconds. > > After some tests it showed extraordinarily effective. For instance > testing with the "All" directory from: > > http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10.… > > it was roughly using 2 to 3 times less CPU (in my notebook) than > using the FltkPlatform::generalIdle() throttling patch. > > Some glitches remained, and while I was working on it, the test > server above went down... :( > > I got a big surprise when after some more tests, it worked quite well > when ignoring everything but calls with asap=true ! :-) > > For instance, now the code reads: > > void FltkViewBase::queueDrawTotal (bool asap) > { > static time_t lastRedraw = 0; > > //if (asap || time(0) > lastRedraw + 2) { > if (asap) { > redraw (DAMAGE_EXPOSE); > lastRedraw = time(0); > } > } If I understand this correctly, the patch now is equivalent to removing the calls to queueDrawTotal(), where asap == false, right? With this patch I see missing screen updates e.g. when resizing the window. > > (lastRedraw is not used). > > > The patch is much simpler than it looks. Many lines are just > for adding the extra parameter. > > Images on long pages still queue a resize that produces a total > redraw. i.e when an image outside the viewport resizes, the > viewport is redrawn causing flickering. > > This is not completely trivial because the image resize may > change the size of the parent widget, and the parent widget may > affect the viewable area. > > If this can somehow be avoided, for instance testing whether > the parent widget changes its size, it'd be great. > > This part of the code clearly needs a review. I wanted to > commit early so you guys have the chance to play with it. First let me explain how I think the drawing and relayout is designed in dillo2. Please correct me if I'm wrong. * Frequent redraws are good if they update the visible content. E.g. when loading a page over a slow line. Immediate feedback to the user is a great feature of dillo. The screen flickering can be avoided with some double buffer mechanism. * queueResize() calls are put into the code whenever the layout might have changed without worrying too much about performance. To make this efficient, queueResize() or queueDrawTotal() just remembers drawing or resizing should be done at some time in the future. * The idle function mechanism then does the actual work of resizing or redrawing. This way many calls to queueResize() can cause many resize operations, or they can be combined to just single resize depending on when the idle functions are called. When loading the same page, dillo can update the screen frequently if enough CPU is available, or less often, if CPU time is not available. I think this is an excellent concept :-) So what do we need to do? * Make the concept work properly. Here I think we need to improve the code where the idle functions are called so that multiple redraws are really combined especially if there is no CPU available. * Of course we still should reconsider each call to queueDrawTotal() or queueResize() and verify whether it is really necessary. However I think we should favor correctness over speed. That means, whenever the layout might have changed, we must call queueResize(). * It would be nice, if we could decide whether a resizing widget affects the layout that is currently visible, so that we could avoid redrawing in this case. This would avoid redrawing when loading very long pages as the DragonFly package list. But I don't think this is easy. Also we should agree on what we actually want to optimize. I don't think CPU usage or number of redraws are enough. Instead dillo should be usable and "feel fast" on fast and slow or loaded systems (if CPU is available, why not use it?). Cheers, Johannes

Feb. 6, 2008

[PATCH]: Table::apportionRowSpan()

by onepoint＠starurchin.org

On Fri, Feb 01, 2008 at 06:11:58PM -0300, Jorge Arellano Cid wrote: > On Fri, Feb 01, 2008 at 07:49:43PM +0000, Jeremy Henty wrote: > The "obvious right thing" may vary. For instance, what the > algorithm currently does is to proportionally apportion the extra > space (just as Firefox). Good point! I was thinking of sharing the space equally rather than proportionally, but proportionally is better. I think I'll be able to do that in O(n). I've put the rewrite on the back burner for now, as its priority has dropped since the actual breakage that starting me thinking along these lines has been fixed. Regards, Jeremy Henty

Feb. 5, 2008

[experimental patch] excessive redraws (again)

by place＠gobigwest.com

Jorge wrote: > Well an experimental prototype was committed. Looking at remote files now, it often doesn't draw anything at all until Eof.

Feb. 5, 2008

[patch] fix size of select widgets

by jcid＠dillo.org

Hi Johannes, On Mon, Feb 04, 2008 at 04:19:45PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Sat, Feb 02, 2008 at 07:23:17PM -0300, Jorge Arellano Cid wrote: > > On Sat, Feb 02, 2008 at 07:27:20PM +0100, Johannes Hofmann wrote: > > > Here is a small patch to compute the size of select widgets similar > > > to the way it is computed for text input widgets. > > > The width is hardcoded to 10 * size of 'M' in the current font. > > > > I committed a different version that measures the string length > > (as dillo1 and FF). You can test with: > > > > http://www.dillo.org/bugtrack/Dinsert.html > > > > (adding a long string to a local copy is useful). > > > > I doubt that's the right way to do it, but at least it works. > > Please consider it experimental and give it a look. > > I don't think it is valid to compute the size in addItem(). The > style may change later, especially in the future with CSS. > I would propose to do the size computation in sizeRequest(), even if > that looks inefficient (patch below). > That way it is consistent with e.g. FltkLabelButtonResource. Committed with the following comment: // Looks like O(n^2) but the loop is executed one time -> O(n). :-) > While at it, I replaced the hardcoded 20 for the small rectangle on > the right with what FLTK uses for the width of the rectangle. Good. -- Cheers Jorge.-

Feb. 5, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by place＠gobigwest.com

Jorge wrote: > On Sat, Feb 02, 2008 at 10:03:13PM +0000, place wrote: > > Johannes wrote: > > > BTW: have you tried opening that page in dillo1 - it takes ages :-) > > > > Wow... Measuring by clock time: > > > > dillo-fltk 0:07 /* clear_double_buffer(); */ > > dillo-fltk 1:03 clear_double_buffer(); > > > > dillo-0.8.1 2:20 > > > > firefox 2:35 Paging pretty hard the last 30 seconds. I did not dare to > > use the page after it finished. This does not count the > > other 22 seconds it takes just to start up for me. > > You can try with the new patch. dillo-fltk immediate /* clear_double_buffer(); */ dillo-fltk 0:06 clear_double_buffer(); A modest improvement :) :) In fact, it takes longer to destroy the page (0:09) than to build it.

Feb. 5, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by jcid＠dillo.org

On Sat, Feb 02, 2008 at 10:03:13PM +0000, place wrote: > Johannes wrote: > > BTW: have you tried opening that page in dillo1 - it takes ages :-) > > Wow... Measuring by clock time: > > dillo-fltk 0:07 /* clear_double_buffer(); */ > dillo-fltk 1:03 clear_double_buffer(); > > dillo-0.8.1 2:20 > > firefox 2:35 Paging pretty hard the last 30 seconds. I did not dare to > use the page after it finished. This does not count the > other 22 seconds it takes just to start up for me. You can try with the new patch. -- Cheers Jorge.-

Feb. 4, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by jcid＠dillo.org

On Sun, Feb 03, 2008 at 08:32:46PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Sun, Feb 03, 2008 at 02:53:59PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Sun, Feb 03, 2008 at 06:06:39PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > the following patch fixes the problem here: > > > > > > diff -r 4a9e0384d5ca dw/fltkviewbase.cc > > > --- a/dw/fltkviewbase.cc Sat Feb 02 18:35:17 2008 +0100 > > > +++ b/dw/fltkviewbase.cc Sun Feb 03 17:59:04 2008 +0100 > > > @@ -64,7 +64,12 @@ void FltkViewBase::draw () > > > translateCanvasYToViewY (rect->y), > > > rect->width, rect->height); > > > > > > - viewRect.intersect(view); > > > + viewRect.intersect (view); > > > + > > > + rect->x = translateViewXToCanvasX (viewRect.x ()); > > > + rect->y = translateViewYToCanvasY (viewRect.y ()); > > > + rect->width = viewRect.w (); > > > + rect->height = viewRect.h (); > > > > > > if (!viewRect.empty ()) { > > > push_clip (viewRect); > > > > > > > > > > > > It uses the rectangle that has been intersected with the current > > > view area for expose(). > > > > Great! > > > > BTW, I have also found places where an intersection may be missing... > > > > > But the real bug seems to be hidden somewhere in the table draw code. > > > Without the patch, expose was called with a very high area (height > > > was 106497!). > > > > Please try to get to the root of the problem. I'll keep on the > > too-many-redraws problem. Later we can merge the ideas. > > The root cause seems to be an overflow of X11 coordinates. > If you try: > > #include <stdio.h> > #include <fltk/Window.h> > #include <fltk/Widget.h> > #include <fltk/Button.h> > #include <fltk/run.h> > #include <fltk/draw.h> > #include <fltk/damage.h> > using namespace fltk; > > Widget *test; > > class Test : public Widget { > public: > Test(int _x, int _y, int _w, int _h) : Widget(_x, _y, _w, > _h) {}; > > void draw() { > for (int y=1000;y < 70000; y +=10) { > fillrect(0, y, 10, 10); > } > } > }; > > int main(int argc, char **argv) { > Window *window = new Window(300, 180); > window->begin(); > test = new Test(20, 40, 260, 100); > window->end(); > window->show(argc, argv); > return run(); > } > > > > you will see a black bar. If you only count to 60000 instead of > 70000, the window stays gray. > > X11 uses shorts somewhere that can overflow. > So the fix in fltkviewbase.cc is sufficient, I think. Excellent, I'll leave it as is. -- Cheers Jorge.-

Feb. 4, 2008

[experimental patch] excessive redraws (again)

by jcid＠dillo.org

Hi Johannes, On Sun, Feb 03, 2008 at 06:58:23PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Sun, Feb 03, 2008 at 02:44:56PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Fri, Feb 01, 2008 at 07:11:31PM +0100, Johannes Hofmann wrote: > > > Hello, > > > > > > let's get more agressive regarding these excessive redraws :-) > > > > > > Below are two patches. The first one adds a own run method to > > > FltkPlatform. It is pretty similar to what fltk delivers, but this > > > way we can tweak it as we like. Especially when to call our idle > > > functions. > > > > I'm experimenting with another approach because AFAIU throttling > > FLTK idle functions not only affects drawing code. > > My patch does not throttle FLTK idle functions. It just does not use FLTK > idle function mechanism for dillo. It uses an own mechanism so we > can tweak it for our needs independent from what FLTK does. > > > > > So far I have very good results. Stay tuned... > > Great. Well an experimental prototype was committed. The original idea here was to use this new API: void Textblock::flush (bool asap) void FltkViewBase::queueDrawTotal (bool asap) (asap = "As soon as possible") and to call the function inmediately when "asap" is true and to otherwise delay to a tunable number of seconds. After some tests it showed extraordinarily effective. For instance testing with the "All" directory from: http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10.… it was roughly using 2 to 3 times less CPU (in my notebook) than using the FltkPlatform::generalIdle() throttling patch. Some glitches remained, and while I was working on it, the test server above went down... :( I got a big surprise when after some more tests, it worked quite well when ignoring everything but calls with asap=true ! :-) For instance, now the code reads: void FltkViewBase::queueDrawTotal (bool asap) { static time_t lastRedraw = 0; //if (asap || time(0) > lastRedraw + 2) { if (asap) { redraw (DAMAGE_EXPOSE); lastRedraw = time(0); } } (lastRedraw is not used). The patch is much simpler than it looks. Many lines are just for adding the extra parameter. Images on long pages still queue a resize that produces a total redraw. i.e when an image outside the viewport resizes, the viewport is redrawn causing flickering. This is not completely trivial because the image resize may change the size of the parent widget, and the parent widget may affect the viewable area. If this can somehow be avoided, for instance testing whether the parent widget changes its size, it'd be great. This part of the code clearly needs a review. I wanted to commit early so you guys have the chance to play with it. -- Cheers Jorge.-

Feb. 4, 2008

[experimental patch] excessive redraws (again)

by jcid＠dillo.org

On Sun, Feb 03, 2008 at 06:58:23PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Sun, Feb 03, 2008 at 02:44:56PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Fri, Feb 01, 2008 at 07:11:31PM +0100, Johannes Hofmann wrote: > > > Hello, > > > > > > let's get more agressive regarding these excessive redraws :-) > > > > > > Below are two patches. The first one adds a own run method to > > > FltkPlatform. It is pretty similar to what fltk delivers, but this > > > way we can tweak it as we like. Especially when to call our idle > > > functions. > > > > I'm experimenting with another approach because AFAIU throttling > > FLTK idle functions not only affects drawing code. > > My patch does not throttle FLTK idle functions. It just does not use FLTK > idle function mechanism for dillo. It uses an own mechanism so we > can tweak it for our needs independent from what FLTK does. Oh, after a more in-depth review I see you're only throttling when to call FltkPlatform's generalIdle. That's OK. I'm experimentin with a queueResize(bool asap)/flush(bool asap) approach. A couple of glitches remain... -- Cheers Jorge.-

Feb. 4, 2008

patch: conditionally sending Cookie2: Re: [Dillo-dev] Re: patch: cookies string leak

by place＠gobigwest.com

Jorge wrote: > On Fri, Feb 01, 2008 at 06:26:56PM +0000, place wrote: > > Also, what would you think of me either > > > > - stuffing the "Cookie2: $Version=\"1\"\r\n" header into a_Cookies_get(url) > > OK. attached. I renamed it a_Cookies_get_query() in an effort to suggest that it now returned more than just the cookies. Everything looks fine when I watch the headers, but I don't use dillo for anything that _relies_ on cookies working properly. So...anyone who habitually uses cookies might want to give this a bit of a test.

Feb. 4, 2008

[patch] fix size of select widgets

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Sat, Feb 02, 2008 at 07:23:17PM -0300, Jorge Arellano Cid wrote: > On Sat, Feb 02, 2008 at 07:27:20PM +0100, Johannes Hofmann wrote: > > Here is a small patch to compute the size of select widgets similar > > to the way it is computed for text input widgets. > > The width is hardcoded to 10 * size of 'M' in the current font. > > I committed a different version that measures the string length > (as dillo1 and FF). You can test with: > > http://www.dillo.org/bugtrack/Dinsert.html > > (adding a long string to a local copy is useful). > > I doubt that's the right way to do it, but at least it works. > Please consider it experimental and give it a look. I don't think it is valid to compute the size in addItem(). The style may change later, especially in the future with CSS. I would propose to do the size computation in sizeRequest(), even if that looks inefficient (patch below). That way it is consistent with e.g. FltkLabelButtonResource. While at it, I replaced the hardcoded 20 for the small rectangle on the right with what FLTK uses for the width of the rectangle. You can see a difference with e.g: <html> <body> <form> <select> <option>foo</option> <option>bar</option> </select> <h1> <select> <option>foo</option> <option>bar</option> </select> </h1> </form> </body> </html> diff -r 1c41f9a73971 dw/fltkui.cc --- a/dw/fltkui.cc Sun Feb 03 21:13:11 2008 +0100 +++ b/dw/fltkui.cc Mon Feb 04 16:13:00 2008 +0100 @@ -1021,7 +1021,6 @@ FltkOptionMenuResource::FltkOptionMenuRe { init (platform); selection = NULL; - maxStringWidth = 0; } FltkOptionMenuResource::~FltkOptionMenuResource () @@ -1052,9 +1051,20 @@ void FltkOptionMenuResource::sizeRequest if (style) { FltkFont *font = (FltkFont*)style->font; ::fltk::setfont(font->font,font->size); - requisition->width = maxStringWidth + 20 + 2 * RELIEF_X_THICKNESS; + + int maxStringWidth = 0; + for (int i = 0; i < getNumberOfItems (); i++) { + int len = (int)::fltk::getwidth (getItem(i)); + if (len > maxStringWidth) { + maxStringWidth = len; + } + } + requisition->ascent = font->ascent + RELIEF_Y_THICKNESS; requisition->descent = font->descent + RELIEF_Y_THICKNESS; + requisition->width = maxStringWidth + + (requisition->ascent + requisition->descent) * 4 / 5 + + 2 * RELIEF_X_THICKNESS; } else { requisition->width = 1; requisition->ascent = 1; @@ -1065,20 +1075,12 @@ void FltkOptionMenuResource::addItem (co void FltkOptionMenuResource::addItem (const char *str, bool enabled, bool selected) { - if (str) { - FltkFont *font = (FltkFont*)style->font; - ::fltk::setfont(font->font,font->size); - int len = (int)::fltk::getwidth (str); - if (len > maxStringWidth) { - maxStringWidth = len; - queueResize (true); - } - } - FltkSelectionResource<dw::core::ui::OptionMenuResource>::addItem (str,enabled,selected); if (selected) selection = items->get (items->size()-1); + + queueResize (true); } bool FltkOptionMenuResource::isSelected (int index) diff -r 1c41f9a73971 dw/fltkui.hh --- a/dw/fltkui.hh Sun Feb 03 21:13:11 2008 +0100 +++ b/dw/fltkui.hh Mon Feb 04 16:13:00 2008 +0100 @@ -507,7 +507,6 @@ private: private: static void widgetCallback (::fltk::Widget *widget, void *data); void *selection; - int maxStringWidth; public: FltkOptionMenuResource (FltkPlatform *platform); > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 4, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by jcid＠dillo.org

On Sun, Feb 03, 2008 at 07:31:17PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Sun, Feb 03, 2008 at 02:53:59PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Sun, Feb 03, 2008 at 06:06:39PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > the following patch fixes the problem here: > > > > > > diff -r 4a9e0384d5ca dw/fltkviewbase.cc > > > --- a/dw/fltkviewbase.cc Sat Feb 02 18:35:17 2008 +0100 > > > +++ b/dw/fltkviewbase.cc Sun Feb 03 17:59:04 2008 +0100 > > > @@ -64,7 +64,12 @@ void FltkViewBase::draw () > > > translateCanvasYToViewY (rect->y), > > > rect->width, rect->height); > > > > > > - viewRect.intersect(view); > > > + viewRect.intersect (view); > > > + > > > + rect->x = translateViewXToCanvasX (viewRect.x ()); > > > + rect->y = translateViewYToCanvasY (viewRect.y ()); > > > + rect->width = viewRect.w (); > > > + rect->height = viewRect.h (); > > > > > > if (!viewRect.empty ()) { > > > push_clip (viewRect); > > > > > > > > > > > > It uses the rectangle that has been intersected with the current > > > view area for expose(). > > > > Great! > > > > BTW, I have also found places where an intersection may be missing... > > > > > But the real bug seems to be hidden somewhere in the table draw code. > > > Without the patch, expose was called with a very high area (height > > > was 106497!). > > > > Please try to get to the root of the problem. I'll keep on the > > too-many-redraws problem. Later we can merge the ideas. > > > > > This seems to cause problems. Perhaps some overflowing values? > > > With the patch (which is a good optimization anyway), the > > > height of the area that is passed to expose is limited by the > > > current view size. > > > > OK. > > > > It looks like there's no problem to commit this patch. > > I mean it doesn't hide the other bug, right? > > Yes it hides the other bug, but you can commit it anyway. Committed. -- Cheers Jorge.-

Feb. 3, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Sun, Feb 03, 2008 at 02:53:59PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Sun, Feb 03, 2008 at 06:06:39PM +0100, Johannes Hofmann wrote: > > Hi, > > > > the following patch fixes the problem here: > > > > diff -r 4a9e0384d5ca dw/fltkviewbase.cc > > --- a/dw/fltkviewbase.cc Sat Feb 02 18:35:17 2008 +0100 > > +++ b/dw/fltkviewbase.cc Sun Feb 03 17:59:04 2008 +0100 > > @@ -64,7 +64,12 @@ void FltkViewBase::draw () > > translateCanvasYToViewY (rect->y), > > rect->width, rect->height); > > > > - viewRect.intersect(view); > > + viewRect.intersect (view); > > + > > + rect->x = translateViewXToCanvasX (viewRect.x ()); > > + rect->y = translateViewYToCanvasY (viewRect.y ()); > > + rect->width = viewRect.w (); > > + rect->height = viewRect.h (); > > > > if (!viewRect.empty ()) { > > push_clip (viewRect); > > > > > > > > It uses the rectangle that has been intersected with the current > > view area for expose(). > > Great! > > BTW, I have also found places where an intersection may be missing... > > > But the real bug seems to be hidden somewhere in the table draw code. > > Without the patch, expose was called with a very high area (height > > was 106497!). > > Please try to get to the root of the problem. I'll keep on the > too-many-redraws problem. Later we can merge the ideas. The root cause seems to be an overflow of X11 coordinates. If you try: #include <stdio.h> #include <fltk/Window.h> #include <fltk/Widget.h> #include <fltk/Button.h> #include <fltk/run.h> #include <fltk/draw.h> #include <fltk/damage.h> using namespace fltk; Widget *test; class Test : public Widget { public: Test(int _x, int _y, int _w, int _h) : Widget(_x, _y, _w, _h) {}; void draw() { for (int y=1000;y < 70000; y +=10) { fillrect(0, y, 10, 10); } } }; int main(int argc, char **argv) { Window *window = new Window(300, 180); window->begin(); test = new Test(20, 40, 260, 100); window->end(); window->show(argc, argv); return run(); } you will see a black bar. If you only count to 60000 instead of 70000, the window stays gray. X11 uses shorts somewhere that can overflow. So the fix in fltkviewbase.cc is sufficient, I think. Cheers, Johannes > > > This seems to cause problems. Perhaps some overflowing values? > > With the patch (which is a good optimization anyway), the > > height of the area that is passed to expose is limited by the > > current view size. > > OK. > > It looks like there's no problem to commit this patch. > I mean it doesn't hide the other bug, right? > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 3, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Sun, Feb 03, 2008 at 02:53:59PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Sun, Feb 03, 2008 at 06:06:39PM +0100, Johannes Hofmann wrote: > > Hi, > > > > the following patch fixes the problem here: > > > > diff -r 4a9e0384d5ca dw/fltkviewbase.cc > > --- a/dw/fltkviewbase.cc Sat Feb 02 18:35:17 2008 +0100 > > +++ b/dw/fltkviewbase.cc Sun Feb 03 17:59:04 2008 +0100 > > @@ -64,7 +64,12 @@ void FltkViewBase::draw () > > translateCanvasYToViewY (rect->y), > > rect->width, rect->height); > > > > - viewRect.intersect(view); > > + viewRect.intersect (view); > > + > > + rect->x = translateViewXToCanvasX (viewRect.x ()); > > + rect->y = translateViewYToCanvasY (viewRect.y ()); > > + rect->width = viewRect.w (); > > + rect->height = viewRect.h (); > > > > if (!viewRect.empty ()) { > > push_clip (viewRect); > > > > > > > > It uses the rectangle that has been intersected with the current > > view area for expose(). > > Great! > > BTW, I have also found places where an intersection may be missing... > > > But the real bug seems to be hidden somewhere in the table draw code. > > Without the patch, expose was called with a very high area (height > > was 106497!). > > Please try to get to the root of the problem. I'll keep on the > too-many-redraws problem. Later we can merge the ideas. > > > This seems to cause problems. Perhaps some overflowing values? > > With the patch (which is a good optimization anyway), the > > height of the area that is passed to expose is limited by the > > current view size. > > OK. > > It looks like there's no problem to commit this patch. > I mean it doesn't hide the other bug, right? Yes it hides the other bug, but you can commit it anyway. Cheers, Johannes > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 3, 2008

[experimental patch] excessive redraws (again)

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Sun, Feb 03, 2008 at 02:44:56PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Fri, Feb 01, 2008 at 07:11:31PM +0100, Johannes Hofmann wrote: > > Hello, > > > > let's get more agressive regarding these excessive redraws :-) > > > > Below are two patches. The first one adds a own run method to > > FltkPlatform. It is pretty similar to what fltk delivers, but this > > way we can tweak it as we like. Especially when to call our idle > > functions. > > I'm experimenting with another approach because AFAIU throttling > FLTK idle functions not only affects drawing code. My patch does not throttle FLTK idle functions. It just does not use FLTK idle function mechanism for dillo. It uses an own mechanism so we can tweak it for our needs independent from what FLTK does. > > So far I have very good results. Stay tuned... Great. > > > > The other patch changes resizeIdle() a bit. As stated in the > > comments, resizeIdle() can queue a new resizeIdle(). So instead of > > drawing the preliminary layout, then change it and redraw again, we > > now wait until the layout is settled and then draw it. > > Committed. OK. Cheers, Johannes > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 3, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by jcid＠dillo.org

Hi Johannes, On Sun, Feb 03, 2008 at 06:06:39PM +0100, Johannes Hofmann wrote: > Hi, > > the following patch fixes the problem here: > > diff -r 4a9e0384d5ca dw/fltkviewbase.cc > --- a/dw/fltkviewbase.cc Sat Feb 02 18:35:17 2008 +0100 > +++ b/dw/fltkviewbase.cc Sun Feb 03 17:59:04 2008 +0100 > @@ -64,7 +64,12 @@ void FltkViewBase::draw () > translateCanvasYToViewY (rect->y), > rect->width, rect->height); > > - viewRect.intersect(view); > + viewRect.intersect (view); > + > + rect->x = translateViewXToCanvasX (viewRect.x ()); > + rect->y = translateViewYToCanvasY (viewRect.y ()); > + rect->width = viewRect.w (); > + rect->height = viewRect.h (); > > if (!viewRect.empty ()) { > push_clip (viewRect); > > > > It uses the rectangle that has been intersected with the current > view area for expose(). Great! BTW, I have also found places where an intersection may be missing... > But the real bug seems to be hidden somewhere in the table draw code. > Without the patch, expose was called with a very high area (height > was 106497!). Please try to get to the root of the problem. I'll keep on the too-many-redraws problem. Later we can merge the ideas. > This seems to cause problems. Perhaps some overflowing values? > With the patch (which is a good optimization anyway), the > height of the area that is passed to expose is limited by the > current view size. OK. It looks like there's no problem to commit this patch. I mean it doesn't hide the other bug, right? -- Cheers Jorge.-

Feb. 3, 2008

[experimental patch] excessive redraws (again)

by jcid＠dillo.org

Hi Johannes, On Fri, Feb 01, 2008 at 07:11:31PM +0100, Johannes Hofmann wrote: > Hello, > > let's get more agressive regarding these excessive redraws :-) > > Below are two patches. The first one adds a own run method to > FltkPlatform. It is pretty similar to what fltk delivers, but this > way we can tweak it as we like. Especially when to call our idle > functions. I'm experimenting with another approach because AFAIU throttling FLTK idle functions not only affects drawing code. So far I have very good results. Stay tuned... > The other patch changes resizeIdle() a bit. As stated in the > comments, resizeIdle() can queue a new resizeIdle(). So instead of > drawing the preliminary layout, then change it and redraw again, we > now wait until the layout is settled and then draw it. Committed. -- Cheers Jorge.-

Feb. 3, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by Johannes.Hofmann＠gmx.de

Hi, the following patch fixes the problem here: diff -r 4a9e0384d5ca dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Sat Feb 02 18:35:17 2008 +0100 +++ b/dw/fltkviewbase.cc Sun Feb 03 17:59:04 2008 +0100 @@ -64,7 +64,12 @@ void FltkViewBase::draw () translateCanvasYToViewY (rect->y), rect->width, rect->height); - viewRect.intersect(view); + viewRect.intersect (view); + + rect->x = translateViewXToCanvasX (viewRect.x ()); + rect->y = translateViewYToCanvasY (viewRect.y ()); + rect->width = viewRect.w (); + rect->height = viewRect.h (); if (!viewRect.empty ()) { push_clip (viewRect); It uses the rectangle that has been intersected with the current view area for expose(). But the real bug seems to be hidden somewhere in the table draw code. Without the patch, expose was called with a very high area (height was 106497!). This seems to cause problems. Perhaps some overflowing values? With the patch (which is a good optimization anyway), the height of the area that is passed to expose is limited by the current view size. Regards, Johannes On Sat, Feb 02, 2008 at 05:37:51PM -0300, Jorge Arellano Cid wrote: > On Sat, Feb 02, 2008 at 07:59:53PM +0000, place wrote: > > Jorge wrote: > > > BTW, Why when in the bookmarks' modify page, checking a section > > > gives a white mark while checking a URL gives a black one? > > > > > > I prefer the black one. It offers higher contrast. > > > > The > > > > int32_t c = bg->colors[FltkColor::SHADING_NORMAL]; > > int r = (c >> 24) & 0xff, g = (c >> 16) & 0xff, b = (c >> 8) & 0xff; > > bool light = r + g + b > 0x230; > > > > in FltkResource::setWidgetStyle() needs tweaking. > > I see. > > > Let's see... On my display, a test something like > > bool light = (r + g >= 0x150) || (r + g + b >= 0x180) > > might be about right. That's probably not the most > > mathematically concise way to describe that, but anyway... > > > > /* I'm too rusty at scripting languages, so: */ > > > > #include <stdio.h> > > int main(int argc, char **argv) { > > int red, green, blue; > > printf("<table>\n\n"); > > for (red = 0; red < 0x100; red += 0x10) { > > for (green = 0; green < 0x100; green += 0x10) { > > for (blue = 0; blue < 0x100; blue += 0x10) { > > printf("<tr bgcolor=#%02x%02x%02x> <td>\n", red, green, blue); > > printf("<form>\n"); > > printf("<input type=\"text\" value=\"%02x%02x%02x 0x%x\">\n", > > red,green,blue, red+green+blue); > > printf("</form>\n"); > > } > > } > > } > > printf("</table>\n"); > > return 0; > > } > > Funny how with that page I get serious problems with redrawing > widgets. If I load the page and left click the non-widget area, > the widgets dissapear under the bgcolor. If I click on the widgets, > partial redraws are got. > > I'm not yet testing with the latest drawing patch. > > Johannes: would you mind checking this? > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 3, 2008

a_Dialog_text_window() dimensions

by jcid＠dillo.org

On Sat, Feb 02, 2008 at 10:33:17PM +0000, place wrote: > (speaking of my ancient computer... > [it keeps not dying, so I keep not buying a new one]) > > a_Dialog_text_window() dimensions were recently increased to > int wh = 600, ww = 650, bh = 30; > > but my display is small enough that this puts the > close button below the bottom of the screen. > > Perhaps it should be limited by screen dimensions. > Or something based on prefs.height and prefs.width... You're right. Hardcoded numbers getting out of the screen are bad. I left it using prefs.height and prefs.width until someone has a better idea. -- Cheers Jorge.-

Feb. 3, 2008

a_Dialog_text_window() dimensions

by place＠gobigwest.com

(speaking of my ancient computer... [it keeps not dying, so I keep not buying a new one]) a_Dialog_text_window() dimensions were recently increased to int wh = 600, ww = 650, bh = 30; but my display is small enough that this puts the close button below the bottom of the screen. Perhaps it should be limited by screen dimensions. Or something based on prefs.height and prefs.width...

Feb. 2, 2008

[patch] fix size of select widgets

by jcid＠dillo.org

On Sat, Feb 02, 2008 at 07:27:20PM +0100, Johannes Hofmann wrote: > Here is a small patch to compute the size of select widgets similar > to the way it is computed for text input widgets. > The width is hardcoded to 10 * size of 'M' in the current font. I committed a different version that measures the string length (as dillo1 and FF). You can test with: http://www.dillo.org/bugtrack/Dinsert.html (adding a long string to a local copy is useful). I doubt that's the right way to do it, but at least it works. Please consider it experimental and give it a look. -- Cheers Jorge.-

Feb. 2, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by place＠gobigwest.com

Johannes wrote: > BTW: have you tried opening that page in dillo1 - it takes ages :-) Wow... Measuring by clock time: dillo-fltk 0:07 /* clear_double_buffer(); */ dillo-fltk 1:03 clear_double_buffer(); dillo-0.8.1 2:20 firefox 2:35 Paging pretty hard the last 30 seconds. I did not dare to use the page after it finished. This does not count the other 22 seconds it takes just to start up for me.

Feb. 2, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by Johannes.Hofmann＠gmx.de

On Sat, Feb 02, 2008 at 05:37:51PM -0300, Jorge Arellano Cid wrote: > > Funny how with that page I get serious problems with redrawing > widgets. If I load the page and left click the non-widget area, > the widgets dissapear under the bgcolor. If I click on the widgets, > partial redraws are got. > > I'm not yet testing with the latest drawing patch. > > Johannes: would you mind checking this? I see this as well. I will take a look at that. Here it even crashes with: Core was generated by `dillo-fltk'. Program terminated with signal 11, Segmentation fault. #0 0x08063df5 in Html_submit_form2 (html=0x28540b00, form=0x29865380, e_input_idx=1) at html.cc:3923 3923 if (DataStr->str[DataStr->len - 1] == '&') (gdb) bt #0 0x08063df5 in Html_submit_form2 (html=0x28540b00, form=0x29865380, e_input_idx=1) at html.cc:3923 #1 0x0808a88c in dw::core::ui::ButtonResource::ClickedEmitter::emitToReceiver (this=0x287ea310, receiver=0x287ee520, signalNo=0, argc=2, argv=0xbfbff32c) at ui.cc:165 #2 0x0808f771 in loutsignal::Emitter::emitVoid (this=0x287ea310, signalNo=0, argc=2, argv=0xbfbff32c) at signal.cc:81 #3 0x0808af58 in dw::core::ui::ButtonResource::ClickedEmitter::emitClicked (this=0x287ea310, resource=0x287ea300, buttonNo=1) at ui.cc:175 #4 0x0807d79a in dw::core::ui::ButtonResource::emitClicked (this=0x287ea300, buttonNo=1) at ui.hh:348 #5 0x08052c34 in fltk::Widget::do_callback (this=0x287ea340) at /home/hofmann/include/fltk/Widget.h:125 #6 0x08097e6c in fltk::Button::handle (this=0x287ea340, event=2, rectangle=@0xbfbff3e4) at Button.cxx:121 #7 0x080980d4 in fltk::Button::handle (this=0x287ea340, event=2) at Button.cxx:77 #8 0x080e6c2a in fltk::Widget::send (this=0x287ea340, event=2) at Widget.cxx:805 #9 0x080c44a6 in fltk::handle (event=2, window=0x28541000) at run.cxx:1258 #10 0x080caa68 in fltk::handle () at x11/run.cxx:1947 #11 0x080caaac in do_queued_events () at x11/run.cxx:396 #12 0x080cadc6 in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:456 #13 0x080cae61 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:457 #14 0x080caf78 in fltk::run () at run.cxx:393 #15 0x0804eaf1 in main (argc=4096, argv=0xbfbff94c) at dillo.cc:106 (gdb) p DataStr->len $1 = 0 (gdb) Johannes BTW: have you tried opening that page in dillo1 - it takes ages :-) > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 2, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by jcid＠dillo.org

On Sat, Feb 02, 2008 at 07:59:53PM +0000, place wrote: > Jorge wrote: > > BTW, Why when in the bookmarks' modify page, checking a section > > gives a white mark while checking a URL gives a black one? > > > > I prefer the black one. It offers higher contrast. > > The > > int32_t c = bg->colors[FltkColor::SHADING_NORMAL]; > int r = (c >> 24) & 0xff, g = (c >> 16) & 0xff, b = (c >> 8) & 0xff; > bool light = r + g + b > 0x230; > > in FltkResource::setWidgetStyle() needs tweaking. I see. > Let's see... On my display, a test something like > bool light = (r + g >= 0x150) || (r + g + b >= 0x180) > might be about right. That's probably not the most > mathematically concise way to describe that, but anyway... > > /* I'm too rusty at scripting languages, so: */ > > #include <stdio.h> > int main(int argc, char **argv) { > int red, green, blue; > printf("<table>\n\n"); > for (red = 0; red < 0x100; red += 0x10) { > for (green = 0; green < 0x100; green += 0x10) { > for (blue = 0; blue < 0x100; blue += 0x10) { > printf("<tr bgcolor=#%02x%02x%02x> <td>\n", red, green, blue); > printf("<form>\n"); > printf("<input type=\"text\" value=\"%02x%02x%02x 0x%x\">\n", > red,green,blue, red+green+blue); > printf("</form>\n"); > } > } > } > printf("</table>\n"); > return 0; > } Funny how with that page I get serious problems with redrawing widgets. If I load the page and left click the non-widget area, the widgets dissapear under the bgcolor. If I click on the widgets, partial redraws are got. I'm not yet testing with the latest drawing patch. Johannes: would you mind checking this? -- Cheers Jorge.-

Feb. 2, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by place＠gobigwest.com

Jorge wrote: > BTW, Why when in the bookmarks' modify page, checking a section > gives a white mark while checking a URL gives a black one? > > I prefer the black one. It offers higher contrast. The int32_t c = bg->colors[FltkColor::SHADING_NORMAL]; int r = (c >> 24) & 0xff, g = (c >> 16) & 0xff, b = (c >> 8) & 0xff; bool light = r + g + b > 0x230; in FltkResource::setWidgetStyle() needs tweaking. Let's see... On my display, a test something like bool light = (r + g >= 0x150) || (r + g + b >= 0x180) might be about right. That's probably not the most mathematically concise way to describe that, but anyway... /* I'm too rusty at scripting languages, so: */ #include <stdio.h> int main(int argc, char **argv) { int red, green, blue; printf("<table>\n\n"); for (red = 0; red < 0x100; red += 0x10) { for (green = 0; green < 0x100; green += 0x10) { for (blue = 0; blue < 0x100; blue += 0x10) { printf("<tr bgcolor=#%02x%02x%02x> <td>\n", red, green, blue); printf("<form>\n"); printf("<input type=\"text\" value=\"%02x%02x%02x 0x%x\">\n", red,green,blue, red+green+blue); printf("</form>\n"); } } } printf("</table>\n"); return 0; }

Feb. 2, 2008

[patch] fix size of select widgets

by jcid＠dillo.org

On Sat, Feb 02, 2008 at 07:27:20PM +0100, Johannes Hofmann wrote: > Here is a small patch to compute the size of select widgets similar > to the way it is computed for text input widgets. > The width is hardcoded to 10 * size of 'M' in the current font. OK. It'd be good to use the length of the longest string (as dillo1 and FF). -- Cheers Jorge.-

Feb. 2, 2008

[patch] fix size of select widgets

by Johannes.Hofmann＠gmx.de

Here is a small patch to compute the size of select widgets similar to the way it is computed for text input widgets. The width is hardcoded to 10 * size of 'M' in the current font. Regards, Johannes PS: The colored widgets are nice! diff -r 68ee0a55704c dw/fltkui.cc --- a/dw/fltkui.cc Sat Feb 02 18:36:32 2008 +0100 +++ b/dw/fltkui.cc Sat Feb 02 19:20:16 2008 +0100 @@ -1048,10 +1048,21 @@ void FltkOptionMenuResource::widgetCallb void FltkOptionMenuResource::sizeRequest (core::Requisition *requisition) { - /** \bug Random values. */ - requisition->width = 100; - requisition->ascent = 18; - requisition->descent = 5; + if (style) { + FltkFont *font = (FltkFont*)style->font; + ::fltk::setfont(font->font,font->size); + requisition->width = + (int)::fltk::getwidth ("M", 1) * 10 + + 2 * RELIEF_X_THICKNESS; + requisition->ascent = + font->ascent + RELIEF_Y_THICKNESS; + requisition->descent = + font->descent + RELIEF_Y_THICKNESS; + } else { + requisition->width = 1; + requisition->ascent = 1; + requisition->descent = 0; + } }

Feb. 2, 2008

a couple of patches: referer and image_off

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 11:18:30PM +0000, place wrote: > Jorge wrote: > > On Fri, Feb 01, 2008 at 07:38:45PM +0000, place wrote: > > > > In brief, using the same URI, the three options offer good > > > > privacy (because no new information is sent), and if we ever > > > > enable using the referring page, the old comments apply. > > > > > > Whew. > > > > > > See, I ran on the equivalent of "host" for > > > at least a year, and then have been using the > > > equivalent of "path" for at least a year, so > > > the idea that I had somehow been doing something > > > wrong was alarming :) > > > > :-) > > > > Well, in that case you can provide good advice on which is > > better as a default. > > Well, I tried "path" one day when "host" didn't work for > some site, and I had the impression that "path" worked more > consistently, but I wasn't being very scientific about it. It looks like we may default to "path". > Nowadays, if I bother to look at why an image doesn't want > to load, it usually turns out that it was a redirection. > I'd been sort of curious why dillo doesn't follow redirections > for non-root urls, but hadn't gotten around to asking... Non-root redirected images are mainly advertising! :-) -- Cheers Jorge.-

Feb. 2, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by jcid＠dillo.org

On Sat, Feb 02, 2008 at 02:52:18AM +0000, place wrote: > Jorge wrote: > > I like the idea, even the look of coloured widgets, but some people may > > prefer the old look. > > > > Would you implement this as a dillorc2 preference? e.g. > > > > # When set to yes, form elements follow the color style of the page. > > widget_colors=YES > > I ended up calling the pref standard_widget_colors, which > allows the toolkit to use its default colors. > > old behavior: current text color on light grey. > standard_widget_colors=YES: black on light grey. > standard_widget_colors=NO: current text color on current background color. Good! Committed. I left a default to standard when not present in dillorc2, but set it to use the new colors in the example dillorc2. Those reading the list, please test and comment. BTW, Why when in the bookmarks' modify page, checking a section gives a white mark while checking a URL gives a black one? I prefer the black one. It offers higher contrast. -- Cheers Jorge.-

Feb. 2, 2008

patch: Re: [Dillo-dev] an experiment in widget coloring (with code)

by place＠gobigwest.com

Jorge wrote: > I like the idea, even the look of coloured widgets, but some people may > prefer the old look. > > Would you implement this as a dillorc2 preference? e.g. > > # When set to yes, form elements follow the color style of the page. > widget_colors=YES I ended up calling the pref standard_widget_colors, which allows the toolkit to use its default colors. old behavior: current text color on light grey. standard_widget_colors=YES: black on light grey. standard_widget_colors=NO: current text color on current background color.

Feb. 2, 2008

a couple of patches: referer and image_off

by place＠gobigwest.com

Jorge wrote: > On Fri, Feb 01, 2008 at 07:38:45PM +0000, place wrote: > > > In brief, using the same URI, the three options offer good > > > privacy (because no new information is sent), and if we ever > > > enable using the referring page, the old comments apply. > > > > Whew. > > > > See, I ran on the equivalent of "host" for > > at least a year, and then have been using the > > equivalent of "path" for at least a year, so > > the idea that I had somehow been doing something > > wrong was alarming :) > > :-) > > Well, in that case you can provide good advice on which is > better as a default. Well, I tried "path" one day when "host" didn't work for some site, and I had the impression that "path" worked more consistently, but I wasn't being very scientific about it. Nowadays, if I bother to look at why an image doesn't want to load, it usually turns out that it was a redirection. I'd been sort of curious why dillo doesn't follow redirections for non-root urls, but hadn't gotten around to asking...

Feb. 2, 2008

a couple of patches: referer and image_off

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 07:38:45PM +0000, place wrote: > > In brief, using the same URI, the three options offer good > > privacy (because no new information is sent), and if we ever > > enable using the referring page, the old comments apply. > > Whew. > > See, I ran on the equivalent of "host" for > at least a year, and then have been using the > equivalent of "path" for at least a year, so > the idea that I had somehow been doing something > wrong was alarming :) :-) Well, in that case you can provide good advice on which is better as a default. -- Cheers Jorge.-

Feb. 1, 2008

Re: patch: cookies string leak

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 06:26:56PM +0000, place wrote: > Also, what would you think of me either > > - stuffing the "Cookie2: $Version=\"1\"\r\n" header into a_Cookies_get(url) OK. Basically the same way referer is handled. > or > - adding a function to http.c to accomplish the same thing? > ...with a_Cookies_get() changed to show a distinction between > don't-want-cookies and don't-have-cookies. > > I almost never have any cookies enabled, so I'd prefer not to send > the Cookie2 header all of the time when I don't want their cookies. No problem. Leak patch committed. -- Cheers Jorge.-

Feb. 1, 2008

[PATCH]: Table::apportionRowSpan()

by jcid＠dillo.org

Hi, On Fri, Feb 01, 2008 at 07:49:43PM +0000, Jeremy Henty wrote: > On Fri, Feb 01, 2008 at 03:15:13PM -0300, Jorge Arellano Cid wrote: > > On Fri, Feb 01, 2008 at 06:10:39AM +0000, Jeremy Henty wrote: > > > > > > (BTW, I still think there is a case for reworking Dillo's ROWSPAN > > > algorithms along the lines I suggested, but it's nice to fix bugs > > > without such efforts.) > > > > If you want to go further, please keep in the O(n) realm. > > I will. It is easy to calculate the minimum cumulative depths of the > rows in a single pass over the cells, treating all ROWSPAN values in > the same way. (In fact it needs only a small modification to the > current code: my previous patch was so ridiculously over-engineered > that I'm quite embarrassed by it.) The problem is that if you use > those depths then you squash everything up to the top, so that when a > cell spans several rows all the extra space goes into the bottom row. > That might be mathematically correct but it will look just plain > wrong. > > It is easy to do a second pass from the bottom-up to find the > *maximum* cumulative depths (subject to the total height of the table > being minimal); the challenge is to find a way to average those two > sets of values that (a) does something sensible in all cases, (b) does > the obvious right thing in simple cases, ie. if one cell spans n rows > then any spare space is distributed evenly between those rows, and (c) > takes O(n). I think I can do it, but haven't yet coded it. The "obvious right thing" may vary. For instance, what the algorithm currently does is to proportionally apportion the extra space (just as Firefox). e.g. <table border=1> <tr> <td rowspan=3> 1<br>2<br>3<br>4<br>5<br>6<br>7<br>8<br>9<br>10<br> 11<br>12<br>13<br>14<br>15<br>16<br>17<br>18<br>19<br>20 <td>A <tr><td>A<br>B <tr> <td>A<br>B<br>C </tr> </table> Although most probably you're thinking of a more complex case. -- Cheers Jorge.-

Feb. 1, 2008

[PATCH]: Table::apportionRowSpan()

by onepoint＠starurchin.org

On Fri, Feb 01, 2008 at 03:15:13PM -0300, Jorge Arellano Cid wrote: > On Fri, Feb 01, 2008 at 06:10:39AM +0000, Jeremy Henty wrote: > > > > (BTW, I still think there is a case for reworking Dillo's ROWSPAN > > algorithms along the lines I suggested, but it's nice to fix bugs > > without such efforts.) > > If you want to go further, please keep in the O(n) realm. I will. It is easy to calculate the minimum cumulative depths of the rows in a single pass over the cells, treating all ROWSPAN values in the same way. (In fact it needs only a small modification to the current code: my previous patch was so ridiculously over-engineered that I'm quite embarrassed by it.) The problem is that if you use those depths then you squash everything up to the top, so that when a cell spans several rows all the extra space goes into the bottom row. That might be mathematically correct but it will look just plain wrong. It is easy to do a second pass from the bottom-up to find the *maximum* cumulative depths (subject to the total height of the table being minimal); the challenge is to find a way to average those two sets of values that (a) does something sensible in all cases, (b) does the obvious right thing in simple cases, ie. if one cell spans n rows then any spare space is distributed evenly between those rows, and (c) takes O(n). I think I can do it, but haven't yet coded it. Regards, Jeremy Henty

Feb. 1, 2008

[experimental patch] excessive redraws (again)

by Johannes.Hofmann＠gmx.de

Hello, let's get more agressive regarding these excessive redraws :-) Below are two patches. The first one adds a own run method to FltkPlatform. It is pretty similar to what fltk delivers, but this way we can tweak it as we like. Especially when to call our idle functions. The other patch changes resizeIdle() a bit. As stated in the comments, resizeIdle() can queue a new resizeIdle(). So instead of drawing the preliminary layout, then change it and redraw again, we now wait until the layout is settled and then draw it. Please note, that the provided run method was tuned for my computer, so it may need other values on slower/faster machines. Play around with other strategies! Johannes diff --git a/dw/fltkplatform.cc b/dw/fltkplatform.cc --- a/dw/fltkplatform.cc +++ b/dw/fltkplatform.cc @@ -25,6 +25,7 @@ #include <fltk/draw.h> #include <fltk/run.h> #include <fltk/events.h> +#include <fltk/Window.h> #include <stdio.h> namespace dw { @@ -185,6 +186,9 @@ container::typed::HashTable <dw::core::s new container::typed::HashTable <dw::core::style::ColorAttrs, dw::core::style::Color> (false, false); +container::typed::List <FltkPlatform> *FltkPlatform::idlePlatforms = + new container::typed::List <FltkPlatform> (0); + FltkPlatform::FltkPlatform () { layout = NULL; @@ -200,8 +204,7 @@ FltkPlatform::FltkPlatform () FltkPlatform::~FltkPlatform () { - if(idleFuncRunning) - remove_idle (generalStaticIdle, (void*)this); + idlePlatforms->removeRef(this); delete idleQueue; } @@ -241,11 +244,6 @@ int FltkPlatform::textWidth (core::style FltkFont *ff = (FltkFont*) font; setfont (ff->font, ff->size); return (int) getwidth (text, len); -} - -void FltkPlatform::generalStaticIdle (void *data) -{ - ((FltkPlatform*)data)->generalIdle(); } void FltkPlatform::generalIdle () @@ -263,7 +261,7 @@ void FltkPlatform::generalIdle () if(idleQueue->isEmpty()) { idleFuncRunning = false; - remove_idle (generalStaticIdle, (void*)this); + idlePlatforms->removeRef (this); } } @@ -277,8 +275,9 @@ int FltkPlatform::addIdle (void (core::L * idle function, the passed idle function is put into a queue. */ if(!idleFuncRunning) { - add_idle (generalStaticIdle, (void*)this); idleFuncRunning = true; + idlePlatforms->removeRef (this); + idlePlatforms->append (this); } idleFuncId++; @@ -306,7 +305,7 @@ void FltkPlatform::removeIdle (int idleI } if(idleFuncRunning && idleQueue->isEmpty()) - remove_idle (generalStaticIdle, (void*)this); + idlePlatforms->removeRef (this); } @@ -409,5 +408,30 @@ void FltkPlatform::detachResource (ui::F resources->removeRef (resource); } + +int FltkPlatform::run () { + int skipped = 0; + + while (::fltk::Window::first()) { + int r = fltk::wait (0.01); + + if (r == 0 || skipped >= 50) { + skipped = 0; + + for (container::typed::Iterator <FltkPlatform> it = idlePlatforms->iterator (); + it.hasNext (); ) { + FltkPlatform *p = it.getNext (); + + p->generalIdle (); + } + + } else { + skipped++; + } + } + + return 0; +} + } // namespace fltk } // namespace dw diff --git a/dw/fltkplatform.hh b/dw/fltkplatform.hh --- a/dw/fltkplatform.hh +++ b/dw/fltkplatform.hh @@ -94,7 +94,7 @@ private: bool idleFuncRunning; int idleFuncId; - static void generalStaticIdle(void *data); + static container::typed::List <FltkPlatform> *idlePlatforms; void generalIdle(); container::typed::List <FltkView> *views; @@ -163,6 +163,8 @@ public: void attachResource (ui::FltkResource *resource); void detachResource (ui::FltkResource *resource); + + static int run(); }; } // namespace fltk diff --git a/config.h.in b/config.h.in diff --git a/src/dillo.cc b/src/dillo.cc --- a/src/dillo.cc +++ b/src/dillo.cc @@ -23,6 +23,8 @@ #include <fltk/Window.h> #include <fltk/run.h> + +#include "dw/fltkcore.hh" #include "dir.h" #include "uicmd.hh" @@ -103,5 +105,5 @@ int main(int argc, char **argv) a_Nav_push(bw, prefs.start_page); } - return fltk::run(); + return dw::fltk::FltkPlatform::run(); } diff --git a/dw/layout.cc b/dw/layout.cc --- a/dw/layout.cc +++ b/dw/layout.cc @@ -520,58 +520,61 @@ void Layout::updateBgColor () void Layout::resizeIdle () { - // Reset already here, since in this function, queueResize() may be - // called again. - resizeIdleId = -1; - - if (topLevel) { - Requisition requisition; - Allocation allocation; - - topLevel->sizeRequest (&requisition); - - allocation.x = allocation.y = 0; - allocation.width = requisition.width; - allocation.ascent = requisition.ascent; - allocation.descent = requisition.descent; - topLevel->sizeAllocate (&allocation); - - canvasWidth = requisition.width; - canvasAscent = requisition.ascent; - canvasDescent = requisition.descent; - emitter.emitCanvasSizeChanged (canvasWidth, canvasAscent, canvasDescent); + while (resizeIdleId != -1) { + // Reset already here, since in this function, queueResize() may be + // called again. + resizeIdleId = -1; - // Tell the views about the new world size. - for (typed::Iterator <View> it = views->iterator (); it.hasNext (); ) { - View *view = it.getNext (); - view->setCanvasSize (canvasWidth, canvasAscent, canvasDescent); - view->queueDrawTotal (); - } + if (topLevel) { + Requisition requisition; + Allocation allocation; - if (usesViewport) { - int actualHScrollbarThickness = - (canvasWidth > viewportWidth) ? hScrollbarThickness : 0; - int actualVScrollbarThickness = + topLevel->sizeRequest (&requisition); + + allocation.x = allocation.y = 0; + allocation.width = requisition.width; + allocation.ascent = requisition.ascent; + allocation.descent = requisition.descent; + topLevel->sizeAllocate (&allocation); + + canvasWidth = requisition.width; + canvasAscent = requisition.ascent; + canvasDescent = requisition.descent; + + emitter.emitCanvasSizeChanged (canvasWidth, canvasAscent, canvasDescent); + + // Tell the views about the new world size. + for (typed::Iterator <View> it = views->iterator (); it.hasNext (); ) { + View *view = it.getNext (); + view->setCanvasSize (canvasWidth, canvasAscent, canvasDescent); + view->queueDrawTotal (); + } + + if (usesViewport) { + int actualHScrollbarThickness = + (canvasWidth > viewportWidth) ? hScrollbarThickness : 0; + int actualVScrollbarThickness = (canvasAscent + canvasDescent > viewportWidth) ? vScrollbarThickness : 0; - - if (!canvasHeightGreater && - canvasAscent + canvasDescent - > viewportHeight - actualHScrollbarThickness) { - canvasHeightGreater = true; - setSizeHints (); - /* May queue a new resize. */ - } - // Set viewport sizes. - for (typed::Iterator <View> it = views->iterator (); - it.hasNext (); ) { - View *view = it.getNext (); - if (view->usesViewport ()) - view->setViewportSize (viewportWidth, viewportHeight, - actualHScrollbarThickness, - actualVScrollbarThickness); + if (!canvasHeightGreater && + canvasAscent + canvasDescent + > viewportHeight - actualHScrollbarThickness) { + canvasHeightGreater = true; + setSizeHints (); + /* May queue a new resize. */ + } + + // Set viewport sizes. + for (typed::Iterator <View> it = views->iterator (); + it.hasNext (); ) { + View *view = it.getNext (); + if (view->usesViewport ()) + view->setViewportSize (viewportWidth, viewportHeight, + actualHScrollbarThickness, + actualVScrollbarThickness); + } } }

Feb. 1, 2008

[PATCH]: Table::apportionRowSpan()

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 06:10:39AM +0000, Jeremy Henty wrote: > > OK, please ignore my previous attempt at reworking Dillo's ROWSPAN > handling. I have a simple fix for the bugs I reported at > http://starurchin.singularity/dillo/bugs/table_rowspan.html . This > patch tweaks dw::Table::apportionRowSpan() to handle the special case > where all the rows being spanned have zero height. This fixes the > special cases that were breaking without changing the behaviour in any > other case. Committed. > (BTW, I still think there is a case for reworking Dillo's ROWSPAN > algorithms along the lines I suggested, but it's nice to fix bugs > without such efforts.) If you want to go further, please keep in the O(n) realm. -- Cheers Jorge.-

Feb. 1, 2008

a couple of patches: referer and image_off

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 12:39:41AM +0000, place wrote: > Jorge wrote: > > >From the updated dillorc2: > > > > # Set the HTTP Referer information (WARNING: affects privacy) > > * # We use the same URI, not the refering page (to avoid cross-site tracking). > > # none : No referer at all (full privacy). > > # host : Default value. Send same URI's hostname (no sensible info is sent). > > # path : same URI is sent (NO PRIVACY). > > http_referer=host > > What do you mean by "NO PRIVACY"? I meant that if we send the referring page's path, there would be no privacy. Later I changed the referer approach by using the same URI, which worked surprisingly well on tests, and this new approach obsoleted the comments. Note that "path" is not sending the same URI, it strips the query and fragment parts. In brief, using the same URI, the three options offer good privacy (because no new information is sent), and if we ever enable using the referring page, the old comments apply. i.e. Using Same URI: # none : No referer at all (nothing is sent) # host : Default value. Send same URI's hostname (no new info is sent). # path : same URI is sent (no new info is sent). Using referring page (not implemented): # none : No referer at all (nothing is sent) # host : Default value. Send URI's hostname (referring hostname is known). # path : referring URI is sent (NO PRIVACY, fine grained tracking # of the pages/sites you visit). Using referring page only if hostname matches (not implemented): # none : No referer at all (nothing is sent) # host : Default value. Send URI's hostname (no new info is sent). # path : referring URI is sent (NO PRIVACY, fine-grained per-site # tracking of the pages you visit). I'll fix the comments (of implemented part) upon finishing this thread. Thanks for the question. -- Cheers Jorge.-

Feb. 1, 2008

patch: [Dillo-dev] a couple of patches: referer and image_off

by jcid＠dillo.org

On Fri, Feb 01, 2008 at 01:50:35AM +0000, place wrote: > linebreaks... Ooops!, committed. -- Cheers Jorge.-

Feb. 1, 2008

[PATCH]: Table::apportionRowSpan()

by onepoint＠starurchin.org

OK, please ignore my previous attempt at reworking Dillo's ROWSPAN handling. I have a simple fix for the bugs I reported at http://starurchin.singularity/dillo/bugs/table_rowspan.html . This patch tweaks dw::Table::apportionRowSpan() to handle the special case where all the rows being spanned have zero height. This fixes the special cases that were breaking without changing the behaviour in any other case. (BTW, I still think there is a case for reworking Dillo's ROWSPAN algorithms along the lines I suggested, but it's nice to fix bugs without such efforts.) Regards, Jeremy Henty

Feb. 1, 2008

patch: [Dillo-dev] a couple of patches: referer and image_off

by place＠gobigwest.com

linebreaks... diff -pur dillo2/src/IO/http.c dillo2-cur/src/IO/http.c --- dillo2/src/IO/http.c 2008-01-31 23:55:04.000000000 +0000 +++ dillo2-cur/src/IO/http.c 2008-02-01 01:40:08.000000000 +0000 @@ -158,11 +158,11 @@ static char *Http_get_referer(const Dill if (!strcmp(prefs.http_referer, "host")) { referer = dStrconcat("Referer: ", URL_SCHEME(url), "://", - URL_AUTHORITY(url), "/", NULL); + URL_AUTHORITY(url), "/\r\n", NULL); } else if (!strcmp(prefs.http_referer, "path")) { referer = dStrconcat("Referer: ", URL_SCHEME(url), "://", URL_AUTHORITY(url), - URL_PATH_(url) ? URL_PATH(url) : "/", NULL); + URL_PATH_(url) ? URL_PATH(url) : "/", "\r\n", NULL); } if (!referer) referer = strdup("");

Feb. 1, 2008