- Dillo-dev - lists.mailman3.com

Resp.: [Dillo-dev] Dillo screenshot on my ipaq

by acassis＠gmail.com

Hi Andreas, 2008/2/8, Andreas Kemnade <akemnade(a)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). > Nice work! Do you think to create a OpenEmbedded package? Please send this email at OpenEmbedded and GPE mailing list. I think more people will be interest on this. > Greetings > Andreas Kemnade > Cheers, Alan

Feb. 8, 2008

[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