Dev Build 3157 is out now at https://www.sublimetext.com/3dev, solving some issues on macOS when using colored titlebars, as well fixing the Command Palette regression in 3156
Dev Build 3157
Nice! Would you guys mind explaining what was required to fix the OSX issues? Just curious.
Was kinda secretly hoping for a fix for the Sierra tabs fullscreen bug with all that work on the rendering pipeline. Sadly, it’s still there. I guess everyone has their favourite bug, this is mine I did notice Virtual Box sometimes has the same problem, so perhaps it’s just something wonky in macOS?
I tried rewriting the rendering backend a few different ways to use Core Animation instead of NSOpenGLView, but we were never able to get the performance we needed in terms of getting the composited pixels to the screen. This probably is in part due to the architecture of how Sublime composites everything on the CPU (in a cross-platform way) and then pushes all of the composited pixels to the screen using OS-specific APIs. However, Windows doesn’t seem to run into this issue, so part of it seems to be Apple API overhead.
We use OpenGL on Macs for retina and other high resolution screens because Core Graphics can’t seem to send pixels fast enough. Instead, we create OpenGL textures in a tiled fashion and move them using OpenGL until new tiles are required.
In the end we determined that it appears when you have an NSOpenGLView inside of an NSWindow using the NSFullSizeContentViewWindowMask
flag, and a GPU change occurs, the NSOpenGLView’s context (or something along those lines) gets stuck on the previous GPU. To display the window, all textures and OpenGL command appear to have to be shuffled through main memory to the active GPU, resulting in the increased CPU usage.
In the end, we had to hook into an event that notified us of a screen change (although Apple doesn’t actually document the constant sent to the notification function when a GPU change occurs). When that happens, we discard all textures and references to them, then create a new NSOpenGLView in place of the existing one.
Outstanding! I’ve been eagerly awaiting this one. Congratulations, @wbond and @jps on squashing the bug.
any chance to get the syntax test runner enabled on the sublimehq Packages repo now please?
Anything worth knowing regarding the “various syntax highlight improvements” mentioned in the changelogs?
not sure how we’re supposed to know what you consider to be worth knowing, but just check the commits:
Fair point. I was curious wether that entry mesnt improvements in terms of performance or maybe of functionality for syntax creators. It turned out it was mostly improvements to several concrete language syntaxes, from what I can see. Thank you for the link!
Is go to symbol within the current file completely broken in this build for anyone else?
there still seems to be a sporadic bug in the syntax highlighter, whereby editing a line can cause subsequent lines to end up in the wrong context. No idea how to reproduce it, I’m afraid, but just now I was editing a small C# file, and added /*
to the start of a line which had public interface Blah // line comment here
on it, and the {
on the next line still had the meta.interface
scope with no comment.block
scope to be seen. Reloading the file fixed the problem.
Thanks for the report. I’ll see if I can do some digging and figure out what might be going on here.
Since upgrading to 3157 (macOS 10.13.3), double-clicks on results in the Find Results tabs jump to the corresponding file, but a different tab gets the focus. I wasn’t able to reproduce this with only a few tabs open. This only seems to happen when the file wasn’t open before, since a second double-click on the same result focuses the correct tab.
Edit: I’ll have to investigate this further, the problem could be caused by the Zen Tabs package.
I’ve noticed that Sublime closes when unplugging my external monitor. I’m sure it happens at other times too but i’ve not been able to reliably reproduce those instances.
I wonder if anyone else had noticed something similar?
Can you create an issue at https://github.com/SublimeTextIssues/Core/issues with details?
My hunch would be some sort of package issue, or an issue that existed before. I don’t believe we’ve touched anything related to that in a bit.
Have anyone ever noticed that on mac when a dark colored titlebar meets bright text, the text looks bold in a way that feels unnatural?
And then If you try black titlebar with black text, you’ll see a white “outline”, which is actually antialiasing which assumes bright background. This answers why the bright text on black colored titlebar looks bold and unnatural.
I’ve had Zen Tabs disabled throughout last week without the problem recurring again. Will submit an issue for the package.
Yes. Unfortunately this is something that Apple does automatically, and I don’t believe we have any way to 100% influence it. Apple only allows limited control over the title bar, and we have to do a bunch of hacks to try and create a fully custom color for the background and foreground. If I recall correctly from my testing, we ask for text to be in a certain color, and Apple is sending it back aliased against a background. It probably has something to do with the fact that the text is in a transparent view that overlays a full-window content view (which allows us to control the background color).
Until Apple releases APIs that allow for custom title bars with traditional window title and icon, we’ll have to fake it as best we can.