Sublime Forum

Mac OS X screen sharing and sublime

#1

I screen share quite a bit.

I use a blinky cursor.

If sublime is the foreground application my screen sharing uses about 400 kb/sec. If it’s not the foreground app, my bandwidth usage goes down to about 10 kb/sec, depending on whether I am changing anything on my screen.

So, for some reason, screen sharing thinks that blinking the cursor has invalidated the entire window and this its entire contents must be sent over the wire to the other side.

Is there anything that can be done about it? Have I interpreted the data correctly?

0 Likes
#2

What screen sharing application are you using? Or is it a built in OSX thing?

Maybe the way it works is to transmit the entire window contents when something changes, rather than just the region that changed?

0 Likes
#3

Nope - it’s just Sublime that acts this way.

It’s the screen sharing built-in to Mac OS X. I access using the Messages app, but that just performs the handshake which then launches the Screen Sharing app.

Other apps that blink the cursor do not “invalidate” for lack of a better word the entire window. So i assume it has something to do with what Sublime is actually … doing …

Thanks for the reply…

0 Likes
#4

I’m pretty sure that with all the rendering improvements the ST3 devs made recently, that ST doesn’t refresh the entire window unnecessarily.

You could try setting "gpu_window_buffer": true and "caret_style": "blink" in your User preferences to see if it makes any difference.

1 Like
#5

The recent rendering improvements on OS X are that we only re-composite the parts of the Sublime Text window that have changed.

Depending on the resolution of your screen and the value of gpu_window_buffer, we either use OpenGL or CoreGraphics to draw the composited interface onto your screen. My guess is that your screen sharing application has to treat everything as changed since it isn’t tracking the pixels itself.

2 Likes
#6

For the scenario with a single blinking caret, all versions of Sublime Text have only ever redrawn the pixels covered by the caret (i.e., setNeedsDisplayInRect will be called on the area the caret covers).

The difference between Sublime Text and most Cocoa apps is that Sublime Text only has a single NSView instance for the whole window, rather than one NSView per widget. Perhaps the screen sharing program in question is tracking state on a per-NSView level, and not only transmitting what’s changed.

However, I can’t imagine anyone would make a screen sharing client and not do any inter-frame compression. Perhaps Sublime Text’s use of OpenGL is causing issues here: try setting gpu_window_buffer to false.

2 Likes
#7

Thanks for the tip.

Setting

"gpu_window_buffer": false

seemed to do the trick. The bandwidth dropped for 500 kbytes to 20kb per second.

And the window still seems to scroll as smooth as silk and I have not yet noticed any other slowdowns. And I don’t use the minimap, or anything like that.

JP

0 Likes