- Dillo-dev - lists.mailman3.com

[experimental patch] excessive redraws (again)

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Wed, Feb 13, 2008 at 01:51:50PM -0300, Jorge Arellano Cid wrote: -- snip -- > > Bottom line: > > Main problem: updates of out-of-screen images > produce a full redraw. > (same for large textblocks) > > If we can solve this, the rest may become insignificant! Exactly. Those redraws are unnecessary and should be avoided. > > Please feel free to experiment, propose alternatives, or > implement a better approach that can be committed ASAP! :-) I will try to come up with a fix, but it may take a while since I will be skiing this weekend :-) Independent from that, I'm using my last patch regarding the redraws for quite a while now and it works pretty well here. Doesn't it make dillo2 much more useable for you, or do you see negative effects with it? Cheers, Johannes

Feb. 14, 2008

[experimental patch] excessive redraws (again)

by jcid＠dillo.org

On Mon, Feb 11, 2008 at 06:52:42AM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Sun, Feb 10, 2008 at 03:43:10PM -0300, Jorge Arellano Cid wrote: > > On Fri, Feb 08, 2008 at 02:42:23PM -0300, Jorge Arellano Cid wrote: > > > 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. > > > > OK, I committed an experimental patch that implememts the > > "feel" of the idea (i.e. a draw/flush scheme with a refresh rate) > > > > The rate can be set in fltkviewbase.cc:48. The default value is > > 2 seconds (the idea is to make it a preference). > > > > There's still a lot to review and fix. In fact these are calls > > to drawTotal, and most of them are image updates that should be > > ignored when the image is out of the screen and doesn't resize > > the parent widget. > > > > If refresh rate is set to zero, behaviour gets like before the > > patch (storming updates). If it's set to a high value behaviour > > gets like a raw draw/flush scheme. > > > > Interesting to see that altough many unnecessary update calls > > remain in the code, flickering is reduced a lot, and it starts to > > feel comfortable without double buffer. > > > > > I'll keep on reviewing and expecting your work&comments. > > > > Comments, patches, fixes are welcomed. > > > Yes, that's the way to go I think. Which way? > The decision of when to draw should be done in a central function. > Whether based on a timeout like in your current implementation or some > other method is used to decide when to draw needs to be seen. Yeah, a central function looks like a good idea. (see my previous email for some things this function should consider). > As stated before I would even treat all redraw requests equally and > ignore the asap parameter. Could be. If it tackles the problems explained in the former email. -- Cheers Jorge.-

Feb. 13, 2008

[experimental patch] excessive redraws (again)

by jcid＠dillo.org

Hi Johannes, Please excuse me for my scattered comments these days. I'm travelling visiting some relatives. On Mon, Feb 11, 2008 at 06:44:48AM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Thu, Feb 07, 2008 at 06:32:55PM -0300, Jorge Arellano Cid wrote: > > 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. > > Ok, but how do you know at widget level whether a flush is good or > whether it's better to queue the redraw? At widget level is not easy, and most probably can't be done in the general case. Asap is used as a way to solve these problems: With the patch that ignored redraws with asap=false, asap=true solved the problem of ensuring images were actually drawn sometime (fully updated). The same for main page: asap=true was requested when the network transfer was done, asserting that the main content was updated to the last bit. With the current patch, redraws with (asap==false) are not ignored but queued with a timeout (2 seconds); this ensures images and main pages are drawn. But in this case (asap==true) ensures you don't have to wait the timeout for fast pages. e.g. local files. This scheme allows for minimal CPU usage (big timeout) or fast updates (low or no timeout). If both can be accomplished from a central function without using the asap parameter; great. > > > > 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. > > This is a great example. Think about an html image gallery. A > partial update of the main image is much more important and should > be rendered immediately than a 1x1 pixel spacer that had been loaded > completely. > > My point is, that we can't decide at widget level whether the redraw > should be done now or later. (as explained above). Now, with images, I beleive the main point is to eliminate uneccessary updates (i.e. flickering and wasted CPU time). For instance, I took place's large table (generated from C), and added an <img src='file:/tmp/ball.gif> to every form. That way I had a large page with lots of instances of the same image. Then got the page and image, served through a local cgi-program that can set the transfer speed. Test result: updates of out-of-screen images produced a full redraw. I believe this is the main source of unnecessary redraws. If the image is out-of-screen and it doesn't resize the parent widget, no full resize/redraw is needed. For instance, with the gallery example above, if the small image is updated and the table holding it is not forced a resize when not necessary, the update could be welcomed. Caveat Note: the current implemetation really implements ASAP. This is, the queue function calls redraw directly instead of queuing the redraw for the next idle call (which would be much better). Bottom line: Main problem: updates of out-of-screen images produce a full redraw. (same for large textblocks) If we can solve this, the rest may become insignificant! Please feel free to experiment, propose alternatives, or implement a better approach that can be committed ASAP! :-) -- Cheers Jorge.-

Feb. 13, 2008

[experimental patch] excessive redraws (again)

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Sun, Feb 10, 2008 at 03:43:10PM -0300, Jorge Arellano Cid wrote: > On Fri, Feb 08, 2008 at 02:42:23PM -0300, Jorge Arellano Cid wrote: > > 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. > > OK, I committed an experimental patch that implememts the > "feel" of the idea (i.e. a draw/flush scheme with a refresh rate) > > The rate can be set in fltkviewbase.cc:48. The default value is > 2 seconds (the idea is to make it a preference). > > There's still a lot to review and fix. In fact these are calls > to drawTotal, and most of them are image updates that should be > ignored when the image is out of the screen and doesn't resize > the parent widget. > > If refresh rate is set to zero, behaviour gets like before the > patch (storming updates). If it's set to a high value behaviour > gets like a raw draw/flush scheme. > > Interesting to see that altough many unnecessary update calls > remain in the code, flickering is reduced a lot, and it starts to > feel comfortable without double buffer. > > > I'll keep on reviewing and expecting your work&comments. > > Comments, patches, fixes are welcomed. Yes, that's the way to go I think. The decision of when to draw should be done in a central function. Whether based on a timeout like in your current implementation or some other method is used to decide when to draw needs to be seen. As stated before I would even treat all redraw requests equally and ignore the asap parameter. 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. 11, 2008

[experimental patch] excessive redraws (again)

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Thu, Feb 07, 2008 at 06:32:55PM -0300, Jorge Arellano Cid wrote: > 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. Ok, but how do you know at widget level whether a flush is good or whether it's better to queue the redraw? > > 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. This is a great example. Think about an html image gallery. A partial update of the main image is much more important and should be rendered immediately than a 1x1 pixel spacer that had been loaded completely. My point is, that we can't decide at widget level whether the redraw should be done now or later. > > 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. Yes I also commented out redraw() operations in various places for testing, but it's really difficult to find places where they are completely unnecessary. > > 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, Johannes

Feb. 11, 2008

[experimental patch] excessive redraws (again)

by jcid＠dillo.org

On Sun, Feb 10, 2008 at 09:08:34PM +0000, place wrote: > Jorge wrote: > > OK, I committed an experimental patch that implememts the > > "feel" of the idea (i.e. a draw/flush scheme with a refresh rate) > > > It appears that the new code does not like closed bws: > > ... > a_UIcmd_close_bw > FltkViewBase::queueDrawTotal asap=0 > FltkViewBase::drawTotal > > Program received signal SIGSEGV, Segmentation fault. Oh, yes, a missing timeout function removal in the destructor. Patch committed. -- Cheers Jorge.-

Feb. 11, 2008

patch: multipart/form-data encoding for form submission

by place＠gobigwest.com

Currently, dillo always submits forms using url encoding regardless of the encoding specified by the form. Wikipedia, for example, specifies multipart/form-data because the user may submit huge blocks of text in languages where url encoding will be very inefficient. - This patch always uses the same boundary, but a different one REALLY should be used for every form submission. At the least, the string should be scrambled up somehow. - It adds a URL_MultipartEnc flag. - For the Content-type header, I pull the boundary out of URL_DATA because I didn't want to clutter up the URL with a field for something not commonly used. ----------------------------------------------------------- For multipart/form-data, a submission goes like: [headers] Content-type: multipart/form-data; boundary="[boundary]" --[boundary] Content-Disposition: form-data; name="[name1]" [value1] --[boundary] Content-Disposition: form-data; name="[name2]" [value2] --[boundary] ...and eventually... Content-Disposition: form-data; name="[namen]" [valuen] --[boundary]--

Feb. 11, 2008

[experimental patch] excessive redraws (again)

by place＠gobigwest.com

Jorge wrote: > OK, I committed an experimental patch that implememts the > "feel" of the idea (i.e. a draw/flush scheme with a refresh rate) It appears that the new code does not like closed bws: ... a_UIcmd_close_bw FltkViewBase::queueDrawTotal asap=0 FltkViewBase::drawTotal Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 5381)] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x08094c21 in dw::fltk::FltkViewBase::drawTotal (this=0x81a5ca0) at fltkviewbase.cc:289 #2 0x08094c64 in drawTotalTimeout (data=0x81a5ca0) at fltkviewbase.cc:278 #3 0x080d58b9 in fltk::wait (time_to_wait=0.00186802843) at run.cxx:472 #4 0x080d595d in fltk::run () at run.cxx:393 #5 0x0804ee7a in main (argc=1, argv=0xbffffb44) at dillo.cc:106

Feb. 10, 2008

[experimental patch] excessive redraws (again)

by jcid＠dillo.org

On Fri, Feb 08, 2008 at 02:42:23PM -0300, Jorge Arellano Cid wrote: > 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. OK, I committed an experimental patch that implememts the "feel" of the idea (i.e. a draw/flush scheme with a refresh rate) The rate can be set in fltkviewbase.cc:48. The default value is 2 seconds (the idea is to make it a preference). There's still a lot to review and fix. In fact these are calls to drawTotal, and most of them are image updates that should be ignored when the image is out of the screen and doesn't resize the parent widget. If refresh rate is set to zero, behaviour gets like before the patch (storming updates). If it's set to a high value behaviour gets like a raw draw/flush scheme. Interesting to see that altough many unnecessary update calls remain in the code, flickering is reduced a lot, and it starts to feel comfortable without double buffer. > I'll keep on reviewing and expecting your work&comments. Comments, patches, fixes are welcomed. -- Cheers Jorge.-

Feb. 10, 2008

Dillo screenshot on my ipaq

by jcid＠dillo.org

Hi, On Fri, Feb 08, 2008 at 06:11:08PM +0100, Andreas Kemnade wrote: > Hi, > > I have finally taken the time to make dillo run on my ipaq. > Screenshot: > http://www.tzi.de/~akemnade/dillo-ipaq.png Thanks for the screenshot! > 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... Yeah, at least it works with the nice fonts. > 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). Please excuse my lack of knowledge on the iPAQ. Whad does it involve to get dillo2 running on it? -- Cheers Jorge.-

Feb. 9, 2008