Sublime Forum

"goto anything" performance on retina panels

#1

I have previously complained about the performance of goto anything during typing a filename, but it actually seems worse with the new retina 15". The performance is bad even when not previewing a new file, which makes me think the only logical answer is that sublime is rendering off-screen text for items in that list. The hardware in this thing struggles to render text as it is (sublime scrolls worse than on my 2009 13" macbook pro), so would potentially cause the huge impact I’m seeing.

When typing a filename which matches quite a few results, and keeping that file at the top of the list (by continuing to type the filename) I get an update every 0.5s or so. I can make a video if necessary.

0 Likes

Retina UI lag
Updates for the stable Sublime Text
Support for ST2
Typing very slow/delayed even on small files
#2

I can confirm this. Performance on my retina MBP is subpar.

0 Likes

#3

Okay, after making a video to show this happening, I did find that removing my installed plugins/packages made it a hell of a lot faster, though there is still some latency (which is probably just the document preview rendering — would still love a toggle for that). I will include the video as the text rendering/scroll speed is no different with or without plugins: whrl.pl/RdeQvl

0 Likes

#4

I’ll take a look at this towards the end of the month, which is when Apple tells me my retina macbook will be arriving.

Assuming the bottleneck is purely fill rate, then there are a few options available for optimising this.

0 Likes

#5

It’s definitely not fill rate, but more to do with the rendering of text. So any kind of caching of text will help. I’m guessing Apple will release some kind of documentation regarding this at some point, considering how well they optimised Safari 6.

0 Likes

#6

Unless there’s something fundamentally wrong in the OS X graphics pipeline, it’s almost certainly CPU fill rate. With 4 times as many pixels as most applications are tested with, that’s going to be the component that gets stressed. The GPU will have no issues moving that many pixels, but it doesn’t help applications that rely on the CPU for rendering, which is most of them, including Sublime Text.

With regards to text rendering, Sublime Text already does glyph caching, Core Text isn’t in the critical path.

0 Likes

#7

There are 4 cpu cores with 2 hyper threads each though and blitting graphics is a ridiculously parallelizable task. So if you “own” those routines rather than relying on a library there’s much that can be done.

As for using the gpu instead, not knowing any details of how text rendering is implemented in ST2 couldn’t you just cache the glyphs to 1 or more altas textures and blit using gl?

0 Likes

#8

That’s essentially how S1 works, although there’s a bit more to it to handle sub-pixel anti-aliasing.

0 Likes

#9

You could also draw the curves with triangles using special texture coordinates and shaders as described in GPU Gems 3 which is quite clever IMO. I stumbled upon a piece of code converting ttf-fonts to a format suitable to be rendered that way that looks interesting for my own projects. It’s in a need for some cleanup before it’s usable to me though. I’ll post a github link once I’ve cleaned it up enough to compile and I have a small test working.

0 Likes

#10

For anyone interested: github.com/quarnster/TTF. I havent figured out yet how to properly render triangles marked as tpos.z==+1.0 though.

0 Likes

#11

Oh wow, I didn’t realise you were already optimising to that level. I will do some further testing tomorrow when I’m back at my machine to see if it is in fact capping on CPU, but it honestly would not surprise me if it was an issue with the OS X graphics pipeline based on what I’ve been seeing so far.

0 Likes

#12

Okay, on closer inspection it is definitely maxing a single core at a ratio of 80% ST2 20% WindowServer (roughly).

Here’s a sample when continuously scrolling: puu.sh/FILf
Out of curiosity I also did one for Safari 6, which makes use of QuartzCore instead of CoreGraphics: puu.sh/FIOY

Good luck on this one. Sublime already performs better than the other text editors I tried out there, but it would be amazing to see it be the first one to bring back smooth scrolling to coders using retina displays :).

0 Likes

#13

That would indeed be awesome. I must say that scrolling in Chocolat is a little smoother.

0 Likes

#14

I can confirm this exists on my retina MacBook Pro as well. No plug-ins installed. Full-screen mode is basically unusable at highest resolution.

0 Likes

#15

Same issue here.
Just to add (since no one mentioned this before) there is no lag at all if I set resolution to native one (2880x1800) using SetResX.

UPD: sorry, no lag with “goto anything” repainting, but typing is still slow.

0 Likes

#16

Anyone know if the current nightly build (2218) helps this “goto anything” lag on the retina display? I don’t normally install the nightly builds, but I might this time if this is fixed…

0 Likes

#17

The nightly build does definitely improve performance, but it still isn’t perfect. It will probably make it perform to the point you can begrudgingly use it, if you’re as near as sensitive to this stuff as me :smiley:.

0 Likes

#18

Cool, thanks. On the bright side, after using it all laggy-ish on the retina display for a while, plugging in an external display feels lightning fast. :smile:

0 Likes

#19

I do my primary editing on my cinema display when I’m not on the move, yeah. It soothes the pain :wink:.

0 Likes

#20

Experiencing this on a MBP Retina as well, swapped to the 2218 nightly which did improve a lot. What are the future plans for handling this? When will it be available in a stable version and can more improvement be expected? The snappyness of ST2 was one of the reasons of swapping to it, being like this makes me cry a bit inside :wink:

0 Likes