I’m sure there are many aspects involved…
One of these has been discussed here, so i’ve created a Feedback for that specific one: <https://xojo.com/issue/49566> IDE, Windows: Code Editor doesn’t refresh when Key is being kept pressed
Please write additional isolated Feedback’s (along with example project, screen recordings, …) with other aspects you encounter while using the Windows IDE. So Xojo can improve it step-by-step.
In versions prior to 2017r2 the backspace key at least rendered properly when held in. In 2017r2 no rendering is done until the key is let up.
I believe this is a separate issue from the one about repeating keys. This issue had shown up for me but now it ‘fixed it’s self’. I can’t get it to happen again, on the same computer.
Greg, whatever the cause is, fact is that we, Win IDE users, are in trouble since Xojo move to D2D. It’s the IDE annoyance and also the fact that most build desktop projects flicker even more than when build with versions prior to the big move So still, I HAVE TO keep 2016R3 up and running.
Follow up in this story: I grabbed an old laptop of the shelf and installed a brand new Win10 PRO. This laptop only has a lousy 2GB RAM, and… It’s WAY better than the other better computer at work.
Now the editor stutters when holding a key, but when casual typing, the editor keeps up (or lags a very little behind). This laptop has an integrated intel GPU with only 1GB of VRAM.
It’s not good, but it’s workable… Will check the GPU and VRAM of the other computer tomorrow at work.
Really weird, it doesn’t seem to be related to how good a PC is, it might be driver related or something?
I also experience typing lag but very manageable. I’m using Windows 10 Home, XOJO R2017 2.1.
BTW,
Have you tried to run xojo under compatibility (right click the XOJO.EXE, Properties>>Compatibility>>Win7 ?
I remember Visual Basic 6 when running on Windows 7. I experienced same trouble with it, the problem was gone after I use the compatibility troubleshooting in windows. Take note, it works on VB6 not on my XOJO.
I am also seeing the repeat-key issue that Julian mentioned. My computer is likely faster than Mathias, as Xojo updates the screen when the key is lifted on my machine. Here is a you-tube video of the repeat-key issue on my machine:
P.S. I have narrated my steps in the video. You may need to turn the volume up on your machine to hear the steps.
Holding the key down, on Windows, behaves almost exactly like a tight loop drawing to a canvas every time
It never gives the runtime a chance to actually redraw
I could force it to refresh, instead of invalidate, but that would likely slow things down a lot more
I have added my current project and a movie to the case (privately). Hopefully @Norman Palardy can replicate this experience. I’ve also updated my graphics driver to the latest version which made no difference.
After updating & rebooting my dev machine Xojo is behaving itself again???
I’m still having issues with the typing speed in windows 2017R2.1. Its a largish project 342 objects currently. Only application running slow this is a native windows box so no virtual stuff here. I also tried changing font settings, removing auto-complete no improvement was seen. Xojo CPU usage goes from about 4% when idle to 25% to 40% when typing depending on how fast I type. Is there a case number I can follow for this issue? I’m thinking about using an external editor for typing my code as the lag is just crazy…anyone had any luck with such a method?
You can use whatever editor you want since its just text - literally - an external editor wont help you with autocomplete etc
There has been work done to address this but its not in a release you can test just yet
There were 4 or 5 different cases and they’ve all been collapsed into one
See case <https://xojo.com/issue/48591>
Update another test i did was type a bunch of code which did not display then switched to notepad to see if anything I had typed would show up there. It did not everything i typed did render in Xojo after the lag so it seems the keys make it to the app so maybe its a rendering problem. My primary PC has 3 monitors was thinking about testing with 2 disabled to see if that had any impact but did not want to try that if others had already done so.
Changing to a single monitor wont have any effect on drawing speed
Slow typing on Windows was already mentioned weeks ago. I also suspect there is a hugh memory leak inside the IDE because Xojo is eating all memory fast. Even after quiting Xojo other applications react very slow or do not even open. When manually releasing RAM, everything works fine again. This happens only after using Xojo.
Its not a big problem, once you know it. I did not try yet to release RAM memory while Xojo is running.
I think the warning message which is shown when opening a project made with a version before 2017 v2 has something to do with it.
Maybe using a version before v2 will solve the slow problem if that is possible for you. This laptop has 6GB of memory and an SSD inside. Besides of the slow typing, I cannot complain.
Chris
[quote=350173:@Norman Palardy]Holding the key down, on Windows, behaves almost exactly like a tight loop drawing to a canvas every time
It never gives the runtime a chance to actually redraw[/quote]
This seems something affecting only Xojo or, better, the last Xojo version(s?).
It’s so compute intensive to refresh the canvas using Direct2D?
What’s the benefit of using Direct2D when all seems slower?
Maybe something is not well tuned in the framework?
Change will always bring unexpected issues. Some more painful than others.
Norman already indicated that Xojo engineers have been working on solving the typing speed issue. Xojo has also indicated that they are working (finally, some might add…) on the flicker issue. Why don’t we collectively cut them some slack and see what improvements they can come up with? As annoying and painful as the typing speed issue may be, our collective insistance borders on harassment. Fixes are coming. Let’s reserve judgment until after the fixes are here. At the same time, I for one appreciate that fixes are not rushed to market. I prefer to wait a bit longer and avoid regressions. In the same line of thought, we pre-release testers should also do our best to “break” the beta, so that any remaining issues and regressions are ironed out prior to general release.
Just my 2 cents.
