Keyboard repeat rate on MAC 17.0.0.8

[rajkej]

During BETA I complained about the keyboard repeat rate using the MAC version of SE. Somebody was able to make a change and the key repeat rate went up at the time. I recently updated my O/S to Mountain Lion 10.8 (from 10.6. and the SE keyboard repeat rate is much slower than I like. For a cursor right/left/up/down key, safari repeats about 115 times in 5 seconds where SE repeats about 50 times in 5 seconds. I have my keyboard repeat rate at its fastest setting in System Preferences and my Delay until repeat at the shortest setting minus one.

Is there some way I can get SE to repeat keys faster? Kinda hard to code quick when the keyboard gets in the way and I'm not a mouse user. Thanks!

[11thPenguin]

Bump!!
I just downloaded the trial to check out the Cocoa native interface and it's pretty painful how slowly keys repeat.  My system settings are maxed out and it's not a problem in any other app.  Is there any way to increase it through SE's config?  (If it's relevant my SE version is 17.0.3.0 and I'm still on OSX 10.6.8 ).

Thanks,
--jonah

[11thPenguin]

With a bit more use it's become clear that my problem isn't just the repeat rate (i.e. the number of times a character is input per second when the key is held down), it's the general update rate of the editor.  I can pretty easily out-type the display update--it's pretty disconcerting to be typing away and have to pause for the editor to catch up.  I haven't done a whole lot of exploration to see if I can adjust something to make it better (e.g. a different font, smaller window, etc.); currently I'm running SE maximized/full-screen on a 27" iMac, with the Menlo font at 11pts.  If it matters, I'm primarily editing Python code and haven't adjusted any of the editing helpers (auto-complete, etc.) from their defaults.

It's going to be pretty disappointing if this is as fast as it gets, and/or if I need to massively change my display setup to get a performance boost.  Anyone have any suggestions, or similar experiences?

--jonah

[Dennis]

Font drawing on Mac OSX is slow, so I'm not surprised your performance is not up to par with that large of a display and that small of a font.  That is a lot of characters to render.

Two suggestions.  I noticed a minor drawing rate improvement switching to the Monaco font.  Drawing performance with Menlo was about 10% slower than Monaco.

The other suggestion, and not for the faint of heart, is to invoke the editor using the arguments
"-graphicssystem raster" to tell Qt to use the raster graphics system.  On all the other platforms, this actually turns out to be slower than the native drawing system, but on the Mac, it actually performs better.  It just does not look very good.  You'll have to close any toolbars you have docked on top because there is a Qt bug that causes them to be drawn in the wrong location.  It's not pretty but it is faster.

[11thPenguin]

Wow, yeah...prompted by Dennis's comments I did some quick tests on various systems where I have SE installed (not a truly fair comparison because my other installs are significantly old versions, but illuminating nonetheless).

On a Linux box with a 27" display, running full-screen, holding down the down-arrow key to just scroll through a file, I was scrolling at about 28 lines per second.  On a Win7 machine with a 30" monitor it was about 30 lps.  Those numbers are up around 1700-1800 characters per minute, which may be where the system repeat rate is set.  The Linux box looked & felt like it was struggling to keep up with that speed, while the Win7 system was cruising along just fine.

On the Mac, my full-screen high was about 18 lps, dropping to 7 lps with the window split into two panels and 5 lps with three (the setup I typically use on my big monitors).  Those latter two work out to something like 60-85 words per minute, which is a pretty achievable speed for a reasonable typist.

That's really not good...like, bordering on unusable not good.   I'm such a huge fan of SlickEdit and would love to be able to use it on my Mac, but the lag may well be a deal-breaker.

--jonah

[chrisant]

It sounds as if either Qt or SE does a full window paint when the window scrolls by 1 line?

I would expect there's a way to get Qt to bitblt move the already-visible lines, and only paint the lines that need to look different. 

Or maybe that optimization exists in SE, but something is defeating in this scenario?

E.g. On Windows the native API to use is ScrollWindowEx to scroll the N-1 lines that were already visible.  Follow up with painting only the lines that need redrawing (the new line that wasn't visible before, and the previously-current line i.e. to remove the current line box around it).

[11thPenguin]

I should maybe clarify that the arrow key was just a convenient test.  I get basically the same results when holding down a letter or etc., i.e. it's the general update speed that's killing it not just the scrolling.

That said, I'm less concerned about what's causing it than I am about whether there's anything I can do to fix it.  So far, a much smaller window and/or larger font seems to be the only thing that helps....

--jonah

[chrisant]

I don't think there's any way to influence how SE paints, aside from window size and font size.

I should maybe clarify that my point was really getting at the principle of minimal repaints in general.  Minimal repaint during scroll involves using bitblt (e.g. ScrollWindowEx) to avoid repainting the majority of the screen.  Minimal repaint when typing a single character involves painting only the affected line.  Etc.

Prior to using Qt, SE didn't do minimal repaints and could repaint the entire screen multiple times from a single keypress, and you could see where one repaint stopped and the next began because it didn't use double buffering.
Along with the switch to Qt, SE began using double buffering, which avoids the flicker from multiple repaints but doesn't solve the overall performance problem from multiple repaints.

Hopefully a future version will take some steps towards more tightly scoped repaints.

[Matthew]

What is hindering our performance (esp scrolling redraws) on the Mac is a slew of extraneous repaint messages. This may be a bug in Qt, but we've not yet isolated it to the point where we can lay such blame. But nevertheless we see paint/redraw messages being sent to windows that have no business redrawing. It's almost as if the entire notion of clipping regions and z-order obscuration is completely disregarded. Frustrating.
We put in a tweak on the Mac that actually treats inactive, fully obscured MDI child windows as wholly invisible. This of course only works when you've got the active editor window maximized to fill the entire MDI area. And this approach is abandoned as soon as child windows are tiled or split. Our new MDI child window architecture for SE2013 should ameliorate this somewhat.
We do use a "bit-blit" double buffering approach, even though on the Mac this is a bit redundant since the Quartz rendering system buffers everything internally (before drawing PostScript to the display). However, this image buffer approach is NOT compatible with Apple's new Retina displays, which handle pixel scaling at the text drawing level. Putting our text lines into an image bypasses these APIs when they go to the screen, resulting in horribly blocky text on Retina displays.

[11thPenguin]

I don't want to be the guy continually flogging a dead horse; I appreciate that this is a known issue.  At the same time, I'm concerned that this isn't getting the engineering attention it really deserves.  For my money the slowness makes SlickEdit/Mac basically unusable -- I'm honestly surprised that it made it through QA and was released as a shipping product in this state -- and some of the comments below ("that is a lot of characters to render", "SE2013 should ameliorate this somewhat") give me the impression that this isn't viewed as the A1, high priority issue I feel it is.

To provide a little context for how bad performance is on the Mac, I did a quick-and-dirty experiment this morning: I installed VirtualBox on my Mac, then installed Win8 on the VirtualBox and installed SlickEdit on the virtualized Win8.  I put the VirtualBox into "seamless" mode (the Win8 windows effectively share the OSX desktop), maximized the SE window, and ran the same timing tests I'd done previously.  This is exactly the same file, the same font, running on the same actual hardware (27" iMac) with the addition of all of VirtualBox's emulation overhead.

Doing my simplistic "hold down the arrow key" test resulted in scroll speeds of 29-ish lines per second, regardless of how many panels I split the window into (as before, I suspect this may be hitting the keyboard repeat rate, not the draw rate).

Compared to the native version, the virtual/emulated Win8 version is about 1.6x the speed for a single full screen window, 4x the speed when the full screen is split into two panels, and almost 6x the speed with three panels.  That is a staggering performance difference!  There are a bunch of issues with running this configuration, but I think with a bit of fine tuning it could be a completely usable setup.

I'd suggest that it is very much a Bad Thing(tm) when the virtual PC version of your product delivers better performance and a more usable overall experience than the Mac native version.

--jonah

[rajkej]

To make sure you get a response, I'd suggest filing a bug on the slickedit.com website. Sometimes the forums don't give you a response because this is not an official channel to report issues. I post my issues here and if I don't get a solution from the community then I file a bug. SE is pretty good at making closure on an actual bug report so you might get better attention that way. Just cut/paste your note below as a bug.