X-Git-Url: http://git.nikiroo.be/?a=blobdiff_plain;f=docs%2Fworklog.md;h=f4a3a36d535b530f32c8210b43f3c4b00462d7c3;hb=be72cb5ccbd42fe304c0acafc380c5636f0d03a2;hp=570404097cc2a5a1be28f3e90a24c07955945539;hpb=e8a11f986bfe2556e450d7b8ad6ef0059b369bbc;p=fanfix.git

diff --git a/docs/worklog.md b/docs/worklog.md
index 5704040..f4a3a36 100644
--- a/docs/worklog.md
+++ b/docs/worklog.md
@@ -1,6 +1,68 @@
 Jexer Work Log
 ==============
 
+August 16, 2017
+
+Holy balls this has gotten so much faster!  It is FINALLY visibly
+identical in speed to the original d-tui: on xterm it is glass
+smooth.  CPU load is about +/- 10%, idling around 5%.
+
+I had to dramatically rework the event processing order, but now it
+makes much more sense.  TApplication.run()'s sole job is to listen for
+backend I/O, push it into drainEventQueue, and wake up the consumer
+thread.  The consumer thread's run() has the job of dealing with the
+event, AND THEN calling doIdles and updating the screen.  That was the
+big breakthrough: why bother having main thread do screen updates?  It
+just leads to contention everywhere as it tries to tell the consumer
+thread to lay off its data structures, when in reality the consumer
+thread should have been the real owner of those structures in the
+first place!  This was mainly an artifact of the d-tui fiber threading
+design.
+
+So now we have nice flow of events:
+
+* I/O enters the backend, backend wakes up main thread.
+
+* Main thread grabs events, wakes up consumer thread.
+
+* Consumer thread does work, updates screen.
+
+* Anyone can call doRepaint() to get a screen update shortly
+  thereafter.
+
+* Same flow for TTerminalWindow: ECMA48 gets remote I/O, calls back
+  into TTerminalWindow, which then calls doRepaint().  So in this case
+  we have a completely external thread asking for a screen update, and
+  it is working.
+
+Along the way I also eliminated the Screen.dirty flag and cut out
+calls to CellAttribute checks.  Overall we now have about 80% less CPU
+being burned and way less latency.  Both HPROF samples and times puts
+my code at roughly 5% of the total, all the rest is the
+sleeping/locking infrastructure.
+
+August 15, 2017
+
+I cut 0.0.5 just now, and also applied for a Sonatype repository.
+It was a reasonable spot: TEditor was working albeit buggy, and a bug
+had just come in on the main TApplication run loop.  So we are about
+to embark upon some performance work again, it's been probably version
+0.0.2 or so since the last cycle.
+
+Code size: 40446 lines.
+
+Now switching head to 0.0.6 and taking a small break.
+
+August 14, 2017
+
+TEditor is basically done.  Mouse movement, keyboard movement,
+backspace / delete / enter / etc. are all in.  Things are starting to
+look pretty good.
+
+I'm going to prep for a final cut and release tag tomorrow or the next
+evening.  I need to take a break and get some meatspace life dealt
+with.
+
 August 12, 2017
 
 TEditor is stubbed in about 50% complete now.  I have a Highlighter
@@ -180,4 +242,3 @@ checklists.  I think I will see if jexer is available at SourceForge,
 and if so grab it.  Perhaps I can put together some good Turbo Vision
 resources too.  At the very least direct people to the Borland-derived
 C++ releases and Free Vision.
-