- Dillo-dev - lists.mailman3.com

Good news from fltk!

by jcid＠dillo.org

On Thu, Apr 17, 2008 at 05:28:34PM +0200, Johannes Hofmann wrote: > On Thu, Apr 17, 2008 at 08:53:23AM -0400, Jorge Arellano Cid wrote: > > On Tue, Apr 15, 2008 at 09:18:23PM +0200, Johannes Hofmann wrote: > > > Hi Jorge, > > > > > > On Tue, Apr 15, 2008 at 02:38:35PM -0400, Jorge Arellano Cid wrote: > > > > Hi Johannes, > > > > > > > > On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > > > > > Hi Jeremy, > > > > > > > > > > On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote: > > > > > > > > > > > > On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > > > > > > > > > > > > > Attached is a patch that enables double buffering for partial screen > > > > > > > redraws (this is where the flickering is most annoying). You will > > > > > > > need at least version r6079 of fltk2 to test. > > > > > > > > > > > > OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch > > > > > > (fixed version). Looks OK so far. Any tests I should run? > > > > > > > > > > Mostly I would be interested whether it still feels fast. And any > > > > > regressions you observe, of course... > > > > > > > > I found something that looks like a bug in double buffering > > > > (it doesn't happen with the previous code). > > > > > > > > If you: > > > > > > > > - ./dillo-fltk about:splash > > > > - scroll down 1 or 2 inches. > > > > - browse to another URL. > > > > - press right mouse button over Back button and return to > > > > the first page. > > > > > > > > You'll end looking to the page through a window artifact in the > > > > control panel. i.e. The page rendering seems to start from below > > > > the control PANEL. > > > > > > > > Please give it a look. > > > > > > Patch 1 should fix the problem. > > > > Good! > > > > Committed. > > > > > > > > The second patch removes the push_clip() / pop_clip() pair that is no > > > longer necessary with double buffering (we only copy the needed > > > rectangle from the backBuffer anyway). > > > It might result in artifacts when running with > > > --disable-doublebuffer however. So I'm not sure if you want to > > > commit that part. > > > > I'd commit bracketed as: > > > > #ifdef NO_DOUBLEBUFFER > > push_clip (viewRect); > > #endif > > > > [Drawing code here...] > > > > > > #ifdef NO_DOUBLEBUFFER > > push_clip (viewRect); > > #endif > > > > > > Would it be OK? > > Yes, of course. Committed. -- Cheers Jorge.-

April 19, 2008

Collapsing whitespace

by Johannes.Hofmann＠gmx.de

On Thu, Apr 17, 2008 at 04:18:52PM -0400, Jorge Arellano Cid wrote: > Hi, > > Just submitted a patch I wanted to make long ago. It deals with > collapsing whitespace. Here's one example: > > http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.2.1 > > BTW, I also changed the bool_t to "unsigned char". Please test > whether it compiles cleanly. Compiles fine here (no warnings). Cheers, Johannes

April 17, 2008

Collapsing whitespace

by jcid＠dillo.org

Hi, Just submitted a patch I wanted to make long ago. It deals with collapsing whitespace. Here's one example: http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.2.1 BTW, I also changed the bool_t to "unsigned char". Please test whether it compiles cleanly. -- Cheers Jorge.-

April 17, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

On Thu, Apr 17, 2008 at 08:53:23AM -0400, Jorge Arellano Cid wrote: > On Tue, Apr 15, 2008 at 09:18:23PM +0200, Johannes Hofmann wrote: > > Hi Jorge, > > > > On Tue, Apr 15, 2008 at 02:38:35PM -0400, Jorge Arellano Cid wrote: > > > Hi Johannes, > > > > > > On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > > > > Hi Jeremy, > > > > > > > > On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote: > > > > > > > > > > On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > > > > > > > > > > > Attached is a patch that enables double buffering for partial screen > > > > > > redraws (this is where the flickering is most annoying). You will > > > > > > need at least version r6079 of fltk2 to test. > > > > > > > > > > OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch > > > > > (fixed version). Looks OK so far. Any tests I should run? > > > > > > > > Mostly I would be interested whether it still feels fast. And any > > > > regressions you observe, of course... > > > > > > I found something that looks like a bug in double buffering > > > (it doesn't happen with the previous code). > > > > > > If you: > > > > > > - ./dillo-fltk about:splash > > > - scroll down 1 or 2 inches. > > > - browse to another URL. > > > - press right mouse button over Back button and return to > > > the first page. > > > > > > You'll end looking to the page through a window artifact in the > > > control panel. i.e. The page rendering seems to start from below > > > the control PANEL. > > > > > > Please give it a look. > > > > Patch 1 should fix the problem. > > Good! > > Committed. > > > > > The second patch removes the push_clip() / pop_clip() pair that is no > > longer necessary with double buffering (we only copy the needed > > rectangle from the backBuffer anyway). > > It might result in artifacts when running with > > --disable-doublebuffer however. So I'm not sure if you want to > > commit that part. > > I'd commit bracketed as: > > #ifdef NO_DOUBLEBUFFER > push_clip (viewRect); > #endif > > [Drawing code here...] > > > #ifdef NO_DOUBLEBUFFER > push_clip (viewRect); > #endif > > > Would it be OK? Yes, of course. Cheers, Johannes

April 17, 2008

patch: image loading on demand for complex button

by corvid＠lavabit.com

(Jorge: Okay. That gives me an opportunity to put this in the priority queue instead.) I was able to get the menus to work for buttons and image inputs, so image loading can be conditional now. My usual disclaimer applies regarding the dw2 side that I did something that made it work, but it may not be the right way.

April 17, 2008

Good news from fltk!

by jcid＠dillo.org

On Tue, Apr 15, 2008 at 09:18:23PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > On Tue, Apr 15, 2008 at 02:38:35PM -0400, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > > > Hi Jeremy, > > > > > > On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote: > > > > > > > > On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > > > > > > > > > Attached is a patch that enables double buffering for partial screen > > > > > redraws (this is where the flickering is most annoying). You will > > > > > need at least version r6079 of fltk2 to test. > > > > > > > > OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch > > > > (fixed version). Looks OK so far. Any tests I should run? > > > > > > Mostly I would be interested whether it still feels fast. And any > > > regressions you observe, of course... > > > > I found something that looks like a bug in double buffering > > (it doesn't happen with the previous code). > > > > If you: > > > > - ./dillo-fltk about:splash > > - scroll down 1 or 2 inches. > > - browse to another URL. > > - press right mouse button over Back button and return to > > the first page. > > > > You'll end looking to the page through a window artifact in the > > control panel. i.e. The page rendering seems to start from below > > the control PANEL. > > > > Please give it a look. > > Patch 1 should fix the problem. Good! Committed. > > The second patch removes the push_clip() / pop_clip() pair that is no > longer necessary with double buffering (we only copy the needed > rectangle from the backBuffer anyway). > It might result in artifacts when running with > --disable-doublebuffer however. So I'm not sure if you want to > commit that part. I'd commit bracketed as: #ifdef NO_DOUBLEBUFFER push_clip (viewRect); #endif [Drawing code here...] #ifdef NO_DOUBLEBUFFER push_clip (viewRect); #endif Would it be OK? -- Cheers Jorge.-

April 17, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Tue, Apr 15, 2008 at 02:38:35PM -0400, Jorge Arellano Cid wrote: > Hi Johannes, > > On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > > Hi Jeremy, > > > > On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote: > > > > > > On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > > > > > > > Attached is a patch that enables double buffering for partial screen > > > > redraws (this is where the flickering is most annoying). You will > > > > need at least version r6079 of fltk2 to test. > > > > > > OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch > > > (fixed version). Looks OK so far. Any tests I should run? > > > > Mostly I would be interested whether it still feels fast. And any > > regressions you observe, of course... > > I found something that looks like a bug in double buffering > (it doesn't happen with the previous code). > > If you: > > - ./dillo-fltk about:splash > - scroll down 1 or 2 inches. > - browse to another URL. > - press right mouse button over Back button and return to > the first page. > > You'll end looking to the page through a window artifact in the > control panel. i.e. The page rendering seems to start from below > the control PANEL. > > Please give it a look. Patch 1 should fix the problem. The second patch removes the push_clip() / pop_clip() pair that is no longer necessary with double buffering (we only copy the needed rectangle from the backBuffer anyway). It might result in artifacts when running with --disable-doublebuffer however. So I'm not sure if you want to commit that part. Cheers, Johannes

April 15, 2008

Re: patch: BUTTON

by corvid＠lavabit.com

Jorge wrote: > On Tue, Apr 15, 2008 at 04:16:55AM +0000, corvid wrote: > > section 17.2.1 says: > > > > "The elements used to create controls generally appear inside a FORM element, > > but may also appear outside of a FORM element declaration when they are used > > to build user interfaces. This is discussed in the section on intrinsic > > events. [p.254] Note that controls outside a form cannot be successful > > controls [p.245]." > > > > ..but I'll make a separate patch for controls outside of forms. > > AFAICS this may be useful with client side scripts, but we're > a long way from suporting scripts. It's also useful if you want to look at a page that explains tags. The page put up a button tag outside of a form to show me what button tags look like. (plus I've already written the code)

April 15, 2008

Good news from fltk!

by jcid＠dillo.org

Hi Johannes, On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > Hi Jeremy, > > On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote: > > > > On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > > > > > Attached is a patch that enables double buffering for partial screen > > > redraws (this is where the flickering is most annoying). You will > > > need at least version r6079 of fltk2 to test. > > > > OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch > > (fixed version). Looks OK so far. Any tests I should run? > > Mostly I would be interested whether it still feels fast. And any > regressions you observe, of course... I found something that looks like a bug in double buffering (it doesn't happen with the previous code). If you: - ./dillo-fltk about:splash - scroll down 1 or 2 inches. - browse to another URL. - press right mouse button over Back button and return to the first page. You'll end looking to the page through a window artifact in the control panel. i.e. The page rendering seems to start from below the control PANEL. Please give it a look. -- Cheers Jorge.-

April 15, 2008

[patch] fix cookies freezing dillo problem

by jcid＠dillo.org

On Fri, Apr 11, 2008 at 11:49:26PM +0200, Andreas Kemnade wrote: > Hi Jorge, > > On Fri, 11 Apr 2008 15:34:49 -0400 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > Note: What still puzzles me, is why accept() returns when > > there's nothing to read. > > > > Hmm, accept() returns when you call connect() on the other side. > Many TCP server programs send stuff to the client before receiving anything > from the client (like ssh servers, smtp servers) so there is nothing unusual > about that. > > So, normally you have > on cookies.dpi side: > accept() > returns after connect() on dillo side > read() > returns after write() on dillo side > > then on dillo side: > read() returns after write() on cookies.dpi side. > > As far as I understand in the race condition case you have: > > dillo cookies.dpi > connect(sock1,...) sock1=accept(....) > connect(sock2,...) (via a_Dpi_send_blocking_cmd) read(sock1,...) > write(sock2,...) (does not block, contents will be added to the recv queue) > read(sock2,...) > > and now, both sides are waiting for data,.... Thanks a lot for the explanation. -- Cheers Jorge.-

April 15, 2008