- Dillo-dev - lists.mailman3.com

[patch] partial redraws - updated

by jcid＠dillo.org

Hi Johannes, On Tue, Dec 04, 2007 at 11:03:01AM +0100, Johannes Hofmann wrote: > On Mon, Dec 03, 2007 at 02:00:07PM -0300, Jorge Arellano Cid wrote: > > On Sun, Dec 02, 2007 at 01:53:14PM +0100, Johannes Hofmann wrote: > > > Hello, > > > > > > this patch fixes the problem pointed out by Sebastian regarding > > > partial redraws and scrolling interference. > > > It adds a new Region class that is implemented similarily > > > as in dillo1 as a set of rectangles not containing each other. > > > The conversion from canvas to view coordinates is now done at > > > draw-time. > > > > Committed! > > Thanks. Attached is another patch that has some improvements to that > code: Excellent. Committed. > * The case that multiple rectangles can be exactly combined to a larger > one is quite likely (other than the comment in dillo1 suggests). > It happens all the time, e.g. when an image is loaded piece by piece. > The region code is improved to take advantage of this. ok. > * A minor bug also present in the dillo1 code is fixed: If a > rectangle existing already in the region is contained in a newly > added rectangle, we must not stop the loop. The new rectangle may > contain other rectangles as well! ok. > * The actual drawing of a region now checks, whether a rectangle is > actually visible at the moment. Does this help to reduce flickering? > * The background is now cleared properly when doing a partial > redraw. This fixes some screen corruption occuring when selecting / > deselecting text. ok. Please excuse me for not having yet the time to review the patch for the scrolling bars. Has Sebastian commented it to you? If not, even when I'm not an expert in dw2, I'd prefer to push forward development in that area and to commit what looks OK. Sebastian will always have the opportunity to comment/fix later. As a matter of fact I'm working of improving table rendering now, and I already have some code that works. It's a complex area that needs some work but I hope to commit a patch this week. BTW, did you receive comments on the patch that lowered CPU consumption when gliding the mouse over pages full of links? -- Cheers Jorge.-

Dec. 4, 2007

[patch] partial redraws - updated

by Johannes.Hofmann＠gmx.de

On Mon, Dec 03, 2007 at 02:00:07PM -0300, Jorge Arellano Cid wrote: > On Sun, Dec 02, 2007 at 01:53:14PM +0100, Johannes Hofmann wrote: > > Hello, > > > > this patch fixes the problem pointed out by Sebastian regarding > > partial redraws and scrolling interference. > > It adds a new Region class that is implemented similarily > > as in dillo1 as a set of rectangles not containing each other. > > The conversion from canvas to view coordinates is now done at > > draw-time. > > Committed! Thanks. Attached is another patch that has some improvements to that code: * The case that multiple rectangles can be exactly combined to a larger one is quite likely (other than the comment in dillo1 suggests). It happens all the time, e.g. when an image is loaded piece by piece. The region code is improved to take advantage of this. * A minor bug also present in the dillo1 code is fixed: If a rectangle existing already in the region is contained in a newly added rectangle, we must not stop the loop. The new rectangle may contain other rectangles as well! * The actual drawing of a region now checks, whether a rectangle is actually visible at the moment. * The background is now cleared properly when doing a partial redraw. This fixes some screen corruption occuring when selecting / deselecting text. Cheers, Johannes > > > PS: The code did not get as complex as I initially thought > > it would :-) > > Great. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 4, 2007

[patch] partial redraws - updated

by jcid＠dillo.org

On Sun, Dec 02, 2007 at 01:53:14PM +0100, Johannes Hofmann wrote: > Hello, > > this patch fixes the problem pointed out by Sebastian regarding > partial redraws and scrolling interference. > It adds a new Region class that is implemented similarily > as in dillo1 as a set of rectangles not containing each other. > The conversion from canvas to view coordinates is now done at > draw-time. Committed! > PS: The code did not get as complex as I initially thought > it would :-) Great. -- Cheers Jorge.-

Dec. 3, 2007

Re: patch: a _minuscule_ amount of cleaning up the header parsing code

by jcid＠dillo.org

On Thu, Nov 29, 2007 at 03:08:12PM +0000, place wrote: > No change in behavior is intended. > Yes, that code is getting hard to understand. After a review, I wondered why Cache_parse_header() is dealing with the message body, when it should only parse the header, and why is it getting the (buf, bufsize) pair when it has the content in entry->Header. It looks that a cleaner way would be something like: (not tested, just pseudo-code) if (!(entry->Flags & CA_GotHeader)) { while ((len = Cache_get_header(entry, buf + start, buf_size - start))) { /* Let's scan, allocate, and set things according to header info */ Cache_parse_header(entry); if (entry->Flags & CA_GotHeader) { start += len; } else // Let the flow continue downward so the remaining // of the buffer is processed } return; } and to get rid of the: dbuf = a_Decode_process(entry->TransferDecoder, dbuf); dbuf = a_Decode_process(entry->ContentDecoder, dbuf); lines inside Cache_parse_header(). Please give it a try. -- Cheers Jorge.-

Dec. 3, 2007

[patch] partial redraws - updated

by Johannes.Hofmann＠gmx.de

Hello, this patch fixes the problem pointed out by Sebastian regarding partial redraws and scrolling interference. It adds a new Region class that is implemented similarily as in dillo1 as a set of rectangles not containing each other. The conversion from canvas to view coordinates is now done at draw-time. Regards, Johannes PS: The code did not get as complex as I initially thought it would :-)

Dec. 2, 2007

Re: charset conversion issues

by place＠gobigwest.com

Jorge wrote: > > - Reach the meta tag and undo/redo within html.cc. > > Somewhat fragile. > > Whatever I might come up with, some html out there would surely find a way > > to outsmart me. > > This is the one I like most at first sight. > > Considering the charset can be given by HTTP or a META element: > > We can assume ASCII in the html text until the HEAD element is > closed. If there's a charset in the META, then the decoder can be > switched from null to the specified one. > > This approach has the advantage of working both when the > charset comes via HTTP or META (<HEAD> content is ASCII). > > We can even add a text buffer for the HEAD element and append > it to the whole HTML content if the offset is hard to set for the > new decoder. > > Do the problems you found apply to this scheme too? My original code worked a bit like this. It would set a flag to make Html_write_raw() quit early and go back up to Html_write() for re-decoding. (It would just restart from the beginning, though, and I would ignore the error messages about multiple heads and so on.) - At least the title tag has to be called again. - Maybe a future dillo that does things with javascript has already seen some and done things with it -- possibly involving literal strings -- by the time we reach meta. I don't know javascript, though, so I don't know whether that's an actual concern. I'm not quite sure what you're saying about the text buffer, though...

Nov. 28, 2007

Re: charset conversion issues

by jcid＠dillo.org

Hi, On Sat, Nov 24, 2007 at 10:50:18PM +0000, place wrote: > With rough code to look at. > No sense polishing up and completing what I have yet when you'll want changes... OK. > > > Charset in the meta tag. > My options seemed to be: > - Client->Callback returns information to cache. > Probably not supposed to happen. Too big of a change. Agreed. At least to postpone until other approaches prove messier. ;-) > - Reach the meta tag and undo/redo within html.cc. > Somewhat fragile. > Whatever I might come up with, some html out there would surely find a way > to outsmart me. This is the one I like most at first sight. Considering the charset can be given by HTTP or a META element: We can assume ASCII in the html text until the HEAD element is closed. If there's a charset in the META, then the decoder can be switched from null to the specified one. This approach has the advantage of working both when the charset comes via HTTP or META (<HEAD> content is ASCII). We can even add a text buffer for the HEAD element and append it to the whole HTML content if the offset is hard to set for the new decoder. Do the problems you found apply to this scheme too? > - Bail out and start again. > This is what I have now. In fact, not knowing at all what to do, I just > call a_Nav_cancel_expect() and a_Nav_push() right then and there. > Surprisingly, it functions instead of crashing, but I'm probably spilling > resources And Violating Principles. > (And, since a_Nav_push() isn't quite right for the situation even then, > I have to fix the nav stack ptr in Nav_cleanup()) > > > There's a dialog box to set the Content-Type for a page. If you change it > to text/plain, you get source in a proper window (with searching) instead > of the little fltk window. No line numbers, though. The idea of using Dillo for view source is interesting, i'm not sure though. Maybe a fltk widget (like an stripped-down editor as the one in FLTK's test/ directory) which gets utf-8 via a_Capi_get_utf8_data(Url) is also good. > > > Not wanting to mess with TypeDet and TypeHdr until finding out what you > think, I stuck in another one, TypeSet. I'd prefer to try to apply the second method (described above). > I'm directly calling a_Cache_[sg]et_content_type() from just wherever, > which may or may not be all right. Cache should be called from Capi only, but at this stage... > I knew that latin1 != UTF-8, but I was not thinking when I wrote > that Decode code. Must've been thinking about the Unicode code numbers. > FLTK has a workaround in it to deal with fools like me who send it latin1 > or cp1252, but better that I stop being foolish :) > > > I don't have Plain or View Source set up to decode yet. I don't know whether > the cache should know about decoding charsets. Or a Text base class or > something. > > > The real-type-matches-header-type code will have to learn to relax a bit, > now that html might contain all kinds of bytes... -- Cheers Jorge.-

Nov. 28, 2007

patch: decode filter (Re: [Dillo-dev] Implemented a weighted apportionment algorithm for table rowspan.)

by jcid＠dillo.org

On Tue, Nov 27, 2007 at 12:25:13AM +0000, place wrote: > Jorge wrote: > > > Oh, and I just read about multiline headers. It wasn't really clear whether > > > this was new in 1.1, though. Did 1.0 have to handle it as well? > > > > Multiline headers?! > > sorry, I don't remember that off the top of my head. > > To answer my own question, the rfc says "HTTP/1.0 headers may be folded onto > multiple lines if each continuation line begins with a space or horizontal tab." > Doesn't look like Cache_parse_field() handles it, though. Must not have been > written with the spec in one hand. I've been through the SPEC lots of times... Even big browsers, like mozilla can't implement every bit of the SPECs (and they have big manpower). In dillo, there're lots of things that are not implemented, and I'm thankful of the people helping to push it forward. -- Cheers Jorge.-

Nov. 27, 2007

patch: decode filter (Re: [Dillo-dev] Implemented a weighted apportionment algorithm for table rowspan.)

by place＠gobigwest.com

Jorge wrote: > > Oh, and I just read about multiline headers. It wasn't really clear whether > > this was new in 1.1, though. Did 1.0 have to handle it as well? > > Multiline headers?! > sorry, I don't remember that off the top of my head. To answer my own question, the rfc says "HTTP/1.0 headers may be folded onto multiple lines if each continuation line begins with a space or horizontal tab." Doesn't look like Cache_parse_field() handles it, though. Must not have been written with the spec in one hand.

Nov. 27, 2007

patch: decode filter (Re: [Dillo-dev] Implemented a weighted apportionment algorithm for table rowspan.)

by jcid＠dillo.org

On Mon, Nov 26, 2007 at 07:24:34PM +0000, place wrote: > > Yes. Send me this. > > All right. Attached. Committed. > > > > > 2) Chunked Transfer-Encoding running on top of (1) because I thought it might > > > help with gzip latency. It was a can-I-get-this-working-in-principle effort > > > and I will have to rewrite it now. Plus I need to actually read through the > > > http/1.1 spec (what I did was just based on a little web page that > > > summarized the main differences between 1.0 and 1.1 for me). > > > > Hmm, yes. Please rewrite it as simple/clean as possible, and with the SPEC > > in one hand. Once there, please send it. > > > > My experience is that code written to comply with the SPEC is easier > > to debug and polish (there're plenty of cases where wrong behaviour is on > > the server side, and thus we can be sure is not dillo). > > It sounds like somebody's indeed had his share of bitter experience with > being sent hacked-together patches :) I wasn't actually threatening to send > this version; just letting you know what's going on... Yes, you're right. 8-P > > The most annoying part so far was that 1.1 is supposedly able to send > "100 Continue" before you get the real stuff. I haven't seen one actually > do it yet, though. Maybe that's only if you're doing pipelining... > > Oh, and I just read about multiline headers. It wasn't really clear whether > this was new in 1.1, though. Did 1.0 have to handle it as well? Multiline headers?! sorry, I don't remember that off the top of my head. -- Cheers Jorge.-

Nov. 27, 2007