February 2008 - Dillo-dev - lists.mailman3.com

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

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