From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 8639777AFE for ; Fri, 28 Jul 2017 15:04:59 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-01v.sys.comcast.net with ESMTP id bDNhdm8iGKh5VbDNod06AA; Fri, 28 Jul 2017 22:05:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1501279520; bh=p8IJ4xhuonS43CG3/UIhxjNTrERDgsBJbgnMQQTuMSg=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=FpCC6UsuuM0RFxquadIg+A31QSlvjfDCv1Lj0ECRxB2Y7MgZiPAo5+vktyihbTJB2 MK5AVbMkEpmwaWzMs2slVswwi3nO6ANdG+4r3nEavYNFEpi6YE52izELfrMXVFMF5V dPy2sGZpVpVxeW2TTulbrx14qaWmwhHuQA33N8q8GXu1ki6t8vt6FzQ+7swSHGbFfY l/0lNDF2+57vkam8jdvnPuxRvvSshg1kf3jIOE+ZdDFbL5MegESJO5fShh5mR+nyR8 lo+Z5UNkMuC6nu/Nbv6W2CHMSRcNee6tN+vucu6gytxZIzLpHVdB8It06YrtnpMglF qE1Sgb9LxAYsA== Received: from unknown ([IPv6:2601:408:c301:784d:21e:4fff:fec2:a0f1]) by resomta-ch2-12v.sys.comcast.net with SMTP id bDNnd0jrHYsxPbDNndvahW; Fri, 28 Jul 2017 22:05:20 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke References: <20170622224940.eklhad@comcast.net> <20170728195103.GE20415@odin> User-Agent: edbrowse/3.7.0x Date: Fri, 28 Jul 2017 18:05:19 -0400 Message-ID: <20170628180519.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-715336 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNun9iZj2KaQEZ3F+a7ShuCNwJfKA5D6G9ihI2ojxtN7+ZIc3/zO2zBnVxenEyZkNUPIwfP/5QOaPzHhhNeLFp1QvLYAQVtaYqolIQxcoTWCpTgSCL/m iVIWPKDF/QZxaLSkCDqNIPkIfKDnXgxRS9zQagWQeyYwf0jaLkT/cPAu Subject: [Edbrowse-dev] JS1 X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 22:04:59 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --nextpart-eb-715336 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > They're kind of authogonal and kind of not. With the separate process = we can > keep spinning round the main input loop even if js is stuck in some = expensive > operation. In theory we could, but today we don't. I send a message over pipe to js process and block read waiting for a = response. Things to consider though: 1. websites aren't going to write js code = that computes a million digits of pi, at least not on purpose. I don't believe there are that many js expensive operations out in the = wild. That's why I didn't mind waiting for the response. Second, I'm calling up the web page and I want to read the page, that = is next on my list of things to do, I really don't want to go off to another buffer and do something else. If it's really that slow I'm going to be annoyed, whether I have the = freedom to switch buffers while I wait or not. It just shouldn't be that slow. A measure of the quality of a mainstream browser is often how quickly = it can bring up complex sweb pages. 3, so far the times it has been really slow is our fault, our DOM was = not correct or complete and that caused js to go into a long loop, = sometimes an infinite loop, and that wouldn't happen on another browser or on edbrowse if we had = all our objects correct. I do understand what you're saying though and we need to keep it in = mind. If the day comes when we say, "wow we just can't give up all control to = js and wait for it to finish", then yes there are advantages to having = it across the street. At this moment I don't thinkg waiting for a js routine to return is a = show stopper, thus the simple design we have now. We'll see. Obviously I'm not doing anything yet that would throw away the 2 = process design. Speaking of serialized poling and timers, one thing I had to do was scale back the intervals, so they can't fire = 20 times a second, as they do on some sites for visual effects. Timers were always running and edbrowse would never listen to what I = was typing at the keyboard. A blind person can't keep up with that kind of rapid fire screen = refresh anyways. So I don't let intervals run more than a couple times per second and = that solves the problem, but it illustrates some of the things we have to think about when = coordinating all these "asynchronous" events. See html.c line 2210. I tell you, if you're running debug 4 or higher, even an interval that = ticks every 2 or 3 seconds is annoying, spewing out periodic and = regular debug messages, and getting in the way of what you're really looking for, but not much = we can do about that. Karl Dahlke --nextpart-eb-715336--