X-Git-Url: http://git.nikiroo.be/?a=blobdiff_plain;f=docs%2Fworklog.md;h=f4a3a36d535b530f32c8210b43f3c4b00462d7c3;hb=be72cb5ccbd42fe304c0acafc380c5636f0d03a2;hp=a169b68cddb6d99c9386a40052d1694f33548df7;hpb=2fef9c6eaa2ba32e7a14ea1e469ec471b05019a2;p=fanfix.git diff --git a/docs/worklog.md b/docs/worklog.md index a169b68..f4a3a36 100644 --- a/docs/worklog.md +++ b/docs/worklog.md @@ -1,6 +1,133 @@ 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 +class that provides different colors based on Word text values, but it +is a lot too simple to do true syntax highlighting. I am noodling on +the right design that would let TEditor be both a programmer's editor +(so Highlighter needs to have state and do a lexical scan) and a word +processor (where Word needs to tokenize on whitespace). I estimate +probably a good 2-4 weeks left to get the editor behavior where I want +it, and then after that will be the 0.0.5 release. + +Finding more minor paper cuts and fixing them: the mouse cursor being +ahead of a window drag event, SwingTerminal resetting blink on new +input, prevent TWindow from resizing down into the status bar. + +August 8, 2017 + +Multiscreen is looking really cool! Demo6 now brings up three +screens, including one that is inside a TWindow of a different +application. + +August 7, 2017 + +Had trouble sleeping, what with a bunch of imaginative thoughts for +this release. jexer.backend will be the ultimate destination for +jexer.session and most of jexer.io. TerminalReader will be the +interface for keyboard and mouse events. cmScreenConnected and +cmScreenDisconnected will be new events to represent a screen +appearing/disappearing, and MultiBackend will be a new backend +multiplexer that goes full XRandR. Several new demos demonstrating +multi-screen support will be coming along. + +August 6, 2017 + +Time to clean up more API, particularly between Backend and Screen. +Both of these will be interfaces soon, so that one could easily +subclass JComponent and implement both Screen and Backend. The +original code evolved out of Qodem, where screen.c and input.c were +two different things leading to ECMA48Screen and ECMA48Terminal, but +now there is really no need to keep them separate. It also +complicates the constructors, as these are basically friend classes +that have used package private access to get around their artificial +separation. + +When I get this done it should be a lot easier to do any of: + +* Pass a JFrame or JComponent to SwingBackend and have it add itself, + like any other Swing widget. + +* Construct a SwingBackend and add it to any regular JComponent. + +* Have multiple TApplications running inside the same Swing + application, including having actions affect each other. (Will also + need to ensure that TWidgets/TWindows are not in different + TApplication collections.) + +* Build a Backend/Screen multiplexer, so that one could have a ECMA48 + TApplication listening on a port and a local Swing monitor for it. + +* Build a Backend/Screen manager, so that one could have multiple + ECMA48 screens acting as a single large screen (e.g. XRandR). + +Now I need to decide which package will collect Backend, SessionInfo, +and Screen. jexer.io has some java.io stuff, so it stays anyway. + July 28, 2017 Got very busy with my meatspace life, now getting a chance to come @@ -115,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. -