Those three things are in. Thanks, I will get on the channel.
http://acid3.acidtests.org
I better get with it, and switch to working off of acidtests. This is
exciting.
Fascinating - acidtests.org blanks, but on db5 it completes!
Maybe this is a good sign.
Kevin
On Tue, 31 Jan 2017, Adam Thompson wrote:
Thanks for fixing this, along with the attributes stuff.
As an interesting note, if you use the latest version on:
http://acid3.acidtests.org
It's fairly clear that the page loads, gets rendered, then blanked by some js
breakage. I've yet to see an error in the output but I've not had time to do
much checking with this new code.
On Mon, Jan 30, 2017 at 06:00:40AM -0500, Karl Dahlke wrote:
Ok,here is the problem of the day.
If you don't apply my latest push / fix, and go to this site, it locks you out
in what seems like an infinite loop.
You can type and type and nothing happens.
Hit control c and get the usual "type qt to quit" message, but still you have
no access.
You have to kill the process. At least that's what happens over here.
http://www.huffingtonpost.com/entry/the-inevitability-of-impeachment_us_588e8d52e4b0b065cbbcd09f
I thought my code was traversing a broken tree forever, again, or some such,
but no.
I fixed those problems.
This site has a half doesn't timers, actually intervals, that fire every 50ms.
My implementation is sufficiently slow, or perhaps I have the wrong priorities
on select() channels, or some such, that I am locked out.
As a bandaid, I now wait at least 230ms before running timers.
That is the latest push.
It's just a couple lines of code.
I actually don't think this is a bad idea.
Timers firing every 50ms almost surely exist to render fast visual effects,
which are lost on us.
If it takes a couple minutes to read a message on the screen, or understand
what part of the screen has changed,
then there's just no reason to change the screen 20 times a second.
Slowing down the process fixes the problem.
I can enter commands and edbrowse responds.
Type db4 and oh yes you can see the timers firing, and the screen rerendering,
even though nothing on the screen changes.
Type db1 to go back to quiet.
It works, though even at this level it consumes 10% of my processor.
If I happen to have 10 such web pages open, either in parallel or pushed up
onto the stack, the whole processor is churning.
So we don't have a clear solution yet.
Obviously the real browsers fire these timers 20 times a second without making
a dent in cpu usage and without blocking user input.
No idea how they do it.
Anyways, the web page works now, and as for its contents, I can only hope he's
right.
Karl Dahlke
_______________________________________________
Edbrowse-dev mailing list
[email protected]
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists
_______________________________________________
Edbrowse-dev mailing list
[email protected]
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
