Hacker News Reader

Comment by ben-schaaf | Hacker News Reader

I can say with confidence that Sublime products will always have a focus on performance. We generally treat any performance issues as high priority and you can see the result of that with most updates shipping some kind of speedup. Sublime Merge 2 for instance has shipped GPU rendering which has seen massive improvements at huge resolutions like 8k. Disclaimer: I work for Sublime HQ.

View on HN

1. I can say I really appreciate the fact that you guys focus so much on performance.

2. I understand that sublime is closed source and respect that, but would sublime ever release or talk about how they develop their GUI? What libraries and techniques they use?

There's a fair amount of information scattered around about how parts of our GUI toolkit work, but there may be a blog post or two about that in the future. In general though it's not a particularly novel design on the toolkit end - the basics are all pretty similar to others. We just tend to put a lot of effort into making things work well and work fast.

I've read that Sublime uses its own custom GUI toolkit. If you had to write Sublime from scratch today, do you think you'd go the same route?

I wasn't there when that decision was made, so it's hard to say, but there's good reasons we tend to re-implement stuff found in existing open source software: Designing and building our own lets us be faster for our specific use case and gives us the control to fix bugs that are performance related or otherwise. It also means we hold a full understanding of the stack in-house allowing us to fix a lot of things. The most painful bugs for us to fix usually come from things we don't have direct control over, like OpenGL drivers, system libraries, etc.

As a hypothetical example if we used GTK instead and it's rendering implementation was designed to be CPU based - say it's based on direct pixel manipulation by passing around a texture - if we wanted to be performant at high resolutions we'd have to refactor/rewrite large parts of GTK to use GPU rendering instead. That would mean either working with the maintainers to get something they'd be happy merging, then doing the work for all of gtk, or forking gtk ripping out the parts we don't use and just refactoring those. The latter would be significantly less work and the likely choice, so we'd likely end up in the same place as before.

May I ask how well you compare with Visual Studio + Visual Assist for Unreal Engine 4 projects on Windows ?

This is not just a performance question.

I've gotten beyond tired of the thousands of paper cuts with the current combo and would love to find a better solution on Windows, even if it is paid.

thanks.

Edit: Just saw it's free to try. going to download it and try out

What about a focus on a roadmap and more frequent updates?

Sure, we've got Sublime Merge 2, but hardly anything for Sublime Text in almost a year (since last September I believe).

And it's not like ST is done and perfect for eternity -- there are several issues still and lots of ways VSC has an edge for example...

You guys are a gem. Probably the best piece of software I use.

Reply on news.ycombinator.com