I finally purchased a new laptop and still have a display delay when typing in notes. Everything else about Logos performance I have tried so far is acceptable on this machine but the annoying notes delay remains. The delay is sporadic and is there whether typing a ten word note in a new note file or typing words at the end of a 1250 word note in my largest file imported from Logos 3. (highlighting the 1200 word note in order to copy it to Word was really slow when I got towards the end as well)
My new machine - Toshiba Satellite P500, i7 740m quad core, 8 GB ram, 64 GB solid state drive, 500 GB 7200 rpm 2nd drive, Nvidia GeForce 330M 1GB dedicated graphics. The only things on the solid state drive are Windows and Logos 4.
I understand from other posts that the note problems are due at least in part to Microsoft issues, but it would be really nice if Logos come up with some fix for this as well as addressing the other note functionality issues many have raised.
Rick Harrell:I understand from other posts that the note problems are due at least in part to Microsoft issues, but it would be really nice if Logos come up with some fix for this as well as addressing the other note functionality issues many have raised.
If there are other note fixes you'd like to see, post your approval in those threads or create a thread for note suggestions. I know Logos is listening to the requests and trust me, they are just as frustrated with the slow typing thing as you are. (If not more so because it's multiplied by all their customers.)
Sarcasm is my love language. Obviously I love you.
Thomas Black:It's definitely a NET issue.
I disagree. If I buy a car that only gets 10 miles per gallon, then it is my fault that I have to spend $$$$ in gas to drive the car. Because Logos decided to use a WPF text editor, then its Logos fault that the note system is substandard.
From Microsoft: If you are seeing sluggish typing WPF is almost certainly not to blame.
This statement does not imply the issue is not .NET, but it shows Microsoft's position.
tom collinge: Thomas Black:It's definitely a NET issue. I disagree. If I buy a car that only gets 10 miles per gallon, then it is my fault that I have to spend $$ in gas to drive the car. Because Logos decided to use a WPF text editor, then its Logos fault that the note system is substandard.
I disagree. If I buy a car that only gets 10 miles per gallon, then it is my fault that I have to spend $$ in gas to drive the car. Because Logos decided to use a WPF text editor, then its Logos fault that the note system is substandard.
Yet, some, like me, don't have this issue, or have it only rarely.
Is that weird, or what?
Help links: WIKI; Logos 6 FAQ. (Phil. 2:14, NIV)
I used to see the issue, but not any more. Did a recent beta release fix it?
As a .NET programmer who's conversant in WPF, I'm open to the idea that WPF might be contributing to the problem. It's definitely *not* the .NET framework as a whole. As an example, Visual Studio 2010 is one massive text editor written in .NET (the 2010 version supposedly completing Microsoft's work to make it completely .NET). It has no hesitation problems whatsoever. I don't think it uses WPF very much, if at all.
Based on the fact that there's significant hesitation in L4 when typing in simple things like search text, resource filters, etc., I'd guess that the issue relates to a specific way that L4 uses WPF (which isn't to say it's necessarily L4's fault). My observation (and this is strictly anecdotal) is that L4 is trying to do something with each keystroke, and this something is what causes the UI latency. If that's an accurate observation, then the culprit may be either WPF's eventing system (too much overhead to react to the keystrokes and raise events within the L4 application) -OR- the logic that L4 tries to execute when it sees the event (or a combination of the two).
If it is anything along these lines, one possible (ugly) fix would be a configuration setting that has the effect of making L4 not receive all the keystroke events. This would mean the user would have to do something explicit to get L4 to recognize that the user is done entering some segment of text (much like what the Enter key does when typing in a name for a layout).
My $.02 ...
Donnie
Rick Harrell: I finally purchased a new laptop and still have a display delay when typing in notes. Everything else about Logos performance I have tried so far is acceptable on this machine but the annoying notes delay remains. The delay is sporadic and is there whether typing a ten word note in a new note file or typing words at the end of a 1250 word note in my largest file imported from Logos 3. (highlighting the 1200 word note in order to copy it to Word was really slow when I got towards the end as well) My new machine - Toshiba Satellite P500, i7 740m quad core, 8 GB ram, 64 GB solid state drive, 500 GB 7200 rpm 2nd drive, Nvidia GeForce 330M 1GB dedicated graphics. The only things on the solid state drive are Windows and Logos 4. I understand from other posts that the note problems are due at least in part to Microsoft issues, but it would be really nice if Logos come up with some fix for this as well as addressing the other note functionality issues many have raised.
I feel your pain. I have been updating some of my notes by changing resources referenced (NRSV for RSV, NA27 for NA26, Holmes Apostolic Fathers for Schaff). If I smoked cigarettes, I could go out for a smoke while the pizza spins. It takes ever so long to accomplish anything. If you find a solution, be sure to publish it here.
georgegfsomsel
יְמֵי־שְׁנוֹתֵינוּ בָהֶם שִׁבְעִים שָׁנָה וְאִם בִּגְבוּרֹת שְׁמוֹנִים שָׁנָה וְרָהְבָּם עָמָל וָאָוֶן
Donnie Hale:If it is anything along these lines, one possible (ugly) fix would be a configuration setting that has the effect of making L4 not receive all the keystroke events. This would mean the user would have to do something explicit to get L4 to recognize that the user is done entering some segment of text (much like what the Enter key does when typing in a name for a layout).
I'm not a programmer, though I used to play around with QBasic, Basic, and the WordPerfect Macro language. This is way beyond me, so take what I'm about to say with a rather large grain of salt.
I think the issue is that Logos is autosaving the data and/or uploading it to the server as it's being typed. This probably explains why some have a lag issue, others don't and some have it infrequently, the difference being the HD buffer cache size, and/or the CPU cache, and/or whatever network caching issues maybe involved, along with , of course, how full that cache is during the time a user is typing. The solution could be to merely delay writing to disk until the user has stopped using the keyboard for a longer period of time.
Whatever the issue is that sees some with no, little, or intermittent issues, it must be somewhat esoteric, as in all of the discussions no common hardware, OS, or software configuration seems to account for the differences, and near identical hardware, os & software situations can see widely different experiences..
George Somsel: If you find a solution, be sure to publish it here.
Not a solution, but here's a work-around: type up your input in another program (even notepad) then copy/paste into L4. Then go smoke a pizza, or whatever it is you need to do. I know that it's a bit inelegant, but it's something.
Richard DeRuiter: I think the issue is that Logos is autosaving the data and/or uploading it to the server as it's being typed. This probably explains why some have a lag issue, others don't and some have it infrequently, the difference being the HD buffer cache size, and/or the CPU cache, and/or whatever network caching issues maybe involved, along with , of course, how full that cache is during the time a user is typing. The solution could be to merely delay writing to disk until the user has stopped using the keyboard for a longer period of time. Whatever the issue is that sees some with no, little, or intermittent issues, it must be somewhat esoteric, as in all of the discussions no common hardware, OS, or software configuration seems to account for the differences, and near identical hardware, os & software situations can see widely different experiences..
That is a thought which crossed my mind too. I think I will try an experiment -- I'll change the program setting regarding using the internet while I'm working on my notes then change it back when I stop. Perhaps it won't keep the gears spinning while I want to work.
George Somsel: I think I will try an experiment -- I'll change the program setting regarding using the internet while I'm working on my notes then change it back when I stop. Perhaps it won't keep the gears spinning while I want to work.
I think I will try an experiment -- I'll change the program setting regarding using the internet while I'm working on my notes then change it back when I stop. Perhaps it won't keep the gears spinning while I want to work.
Even better would be to use Logos completely offline, so there's no chance it's talking to the servers, regardless of the settings you've chosen.
If you try it, I'll be curious what your results are.
Donnie Hale: one possible (ugly) fix would be a configuration setting that has the effect of making L4 not receive all the keystroke events. This would mean the user would have to do something explicit to get L4 to recognize that the user is done entering some segment of text (much like what the Enter key does when typing in a name for a layout).
If I understrand you - that would mean not displaying anything until after you enter the text? that cure would be worse than the disease!
George Somsel: I'll change the program setting regarding using the internet while I'm working on my notes then change it back when I stop.
Tried this a few minutes ago and there is no change that I can see - note delay is still there and still sporadic.
Bob Schaefer: George Somsel: I think I will try an experiment -- I'll change the program setting regarding using the internet while I'm working on my notes then change it back when I stop. Perhaps it won't keep the gears spinning while I want to work. Even better would be to use Logos completely offline, so there's no chance it's talking to the servers, regardless of the settings you've chosen. If you try it, I'll be curious what your results are.
Thus far it does not seem to be very effective. The pizza still spins (perhaps somewhat less).
Rick Harrell: Donnie Hale: one possible (ugly) fix would be a configuration setting that has the effect of making L4 not receive all the keystroke events. This would mean the user would have to do something explicit to get L4 to recognize that the user is done entering some segment of text (much like what the Enter key does when typing in a name for a layout). If I understrand you - that would mean not displaying anything until after you enter the text? that cure would be worse than the disease!
It is nice to know that your work is automatically saved, but perhaps it would be more efficient if it were to be done in the fashion that MS Word does. There it is not saved until you instruct the program to save it (although there are also certain automatic backups at specified intervals -- not immediate backup).
Rick Harrell: If I understrand you - that would mean not displaying anything until after you enter the text? that cure would be worse than the disease!
No, that's not what I meant.
My hypothesis is that, in addition to the normal behavior of a text editor displaying a character immediately after it's typed, Logos has asked WPF to notify it (via an event) each time a character is typed into the editor. Every time Logos gets one of these notifications, it executes some application behavior. If either the effort it takes WPF to respond to and notify Logos of the key presses and/or the application behavior that Logos executes is "slow", it will appear to the user as if typing and character display is much slower than it should be. Given the speed at which some people type, "slow" might be as little as 1/10 of a second.
My proposed "fix", based on this hypothesis, is a configuration setting that causes Logos to bypass asking WPF for these notifications. The text editor would still behave as it does now in terms of accepting and displaying key presses / characters. It would hopefully just be a lot faster at that basic functionality because WPF wouldn't be raising any events and Logos wouldn't be executing its application behavior. But at some point, that typed-in text needs to have something done to it, e.g. saving the note to disk. Since it wouldn't be happening implicitly - that is, with each key press - it would have to be based on some explicit user action (the Enter key, the text entry field losing the cursor focus, etc.).
Some in this thread after my last post speculated that it could be hitting the network for each character typed. That would be extraordinarily poor design, so I doubt it's that. If I were really ambitious, I could run Wireshark while typing into a note to see if any network activity initiated by Logos occurs. But right now, I'm not (really ambitious)... ;)
If it really is something intrinsic to WPF, the variation from one user to the next would have to be due to something different in each user's environment. For example, the interaction between WPF and the graphics display drivers / hardware; background activity or other applications; I/O subsystem performance, etc.
Thanks for the clarification Donnie. although i have been using computers for years (my first was a commodore 64) I am a user not a programmer. I now have the best hardware I can afford, and a new clean system, and still have the delay issue. I do not have this problem or anything similar with any other software including Adobe CS4. I was showing Logos 4 to a Seminary student I am mentoring and they were so struck by this issue they decided to go with the free software that is available until Logos fixes this. I hope Logos addresses this soon.