Cocoa and retina

[Neil Hodgson]

Purchased a MacBook Pro with retina display yesterday and Scintilla seems to behave quite well. Previous work on retina display support was with running a desktop monitor at half resolution.

There is an intermittent bug when scrolling up above the file start with bounce, displaying garbage streaks that look like repetitions of some pixel lines. Can’t reproduce it now. Scrolling has changed on 10.9 (“responsive scrolling”) and can be performed mostly on a background thread although Scintilla isn’t currently opting into responsive scrolling.
https://developer.apple.com/library/mac/releasenotes/AppKit/RN-AppKit/#//apple_ref/doc/uid/TP30000741-CH2-SW28

Updated the project file so it should work with either Xcode 4.6 or 5.0.

The custom reverse arrow cursor (mac_cursor_flipped.png) doesn’t have a retina counterpart so shows as blocky over the margin. If anyone feels like a small project, creating a double-resolution image can fix this.

Neil

[Mike Lischke]

Post by Neil Hodgson
Purchased a MacBook Pro with retina display yesterday and Scintilla seems to behave quite well. Previous work on retina display support was with running a desktop monitor at half resolution.

Welcome in the retina world, Neil :-) These hi-res displays are simply awesome... Still, the display space isn't enough for me so I have 2 external monitors attached to my MacBook Pro Retina. This has the neat side effect that I can test graphics work quickly on both retina and non-retina displays by just dragging it from one monitor to the other.

Post by Neil Hodgson
The custom reverse arrow cursor (mac_cursor_flipped.png) doesn’t have a retina counterpart so shows as blocky over the margin. If anyone feels like a small project, creating a double-resolution image can fix this.

Attached new versions for all 3 images.

Mike

[Neil Hodgson]

Post by Mike Lischke
Attached new versions for all 3 images.

Thanks, committed as
https://sourceforge.net/p/scintilla/code/ci/ceb0350aca55b481e496ba510a31573b8536255c/
https://sourceforge.net/p/scintilla/code/ci/b7f3f147ef6f8c6201cc7ec66da34e07dfa5a975/

Neil

[Mike Lischke]

Post by Neil Hodgson

Post by Mike Lischke
Attached new versions for all 3 images.

Thanks, committed as
https://sourceforge.net/p/scintilla/code/ci/ceb0350aca55b481e496ba510a31573b8536255c/
https://sourceforge.net/p/scintilla/code/ci/b7f3f147ef6f8c6201cc7ec66da34e07dfa5a975/

Neil, is "combine art" enabled in the scintilla project settings (can't check atm). Without that png files are not combined into a tiff file. I remember when I upgraded to XCode 5 it suggested to switch this on, so it's probably not active atm.

Mike

[Neil Hodgson]

Post by Mike Lischke
Neil, is "combine art" enabled in the scintilla project settings (can't check atm). Without that png files are not combined into a tiff file. I remember when I upgraded to XCode 5 it suggested to switch this on, so it's probably not active atm.

Yes, that was enabled today since it was suggested by the settings validator, in this commit:
https://sourceforge.net/p/scintilla/code/ci/2959b87d05557ccb3055931dac09e2ec3ec97462/

Neil

[Neil Hodgson]

Post by Neil Hodgson
There is an intermittent bug when scrolling up above the file start with bounce, displaying garbage streaks that look like repetitions of some pixel lines. Can’t reproduce it now.

Haven’t been able to reproduce that problem but have a new one: thin vertical lines appear when scrolling horizontally towards the start of the line. More likely to appear when scrolling slowly. This may be due to the scroll view moving in screen pixel amounts instead of logical pixels leading to ‘half pixel’ debris.

Neil

[Todd Whiteman]

Post by Neil Hodgson
thin vertical lines appear when scrolling horizontally towards the start of the line. More likely to appear when scrolling slowly. This may be due to the scroll view moving in screen pixel amounts instead of logical pixels leading to ‘half pixel’ debris.

Hi Neil,

I have seen this too - intermittently - especially noticeable when the
screen width/height are 1/2 pixel sizes, e.g. 650.5 x 490.5, leading to
glitchy 1/2 pixel lines.

For me (in Komodo) these lines can also flicker on/off during each caret
on/off paint.

Cheers,
Todd

[Neil Hodgson]

If the scrollWheel: method on SCIContentView is removed, the garbage lines are not seen. Cocoa is doing something unusual here: simply calling [super scrollWheel:] unconditionally does not fix it, so I expect Cocoa is testing whether the class implements scrollWheel: and running a different code path. This is probably caused by 10.9 responsive scrolling changes but I don’t have an installation of 10.8 with a retina display to check.

SCIContentView only implements scrollWheel to check for command+scroll magnification as it just calls super for all other cases. With a touch pad, pinch gestures work for magnify but some users will only have a mouse with a scroll wheel. This is difficult to work around. The majority of OS X users will now have touch pads, many will have retina displays, and few will only have scroll-wheel mice so greatest-happiness-for-the-greatest-number probably means fixing the display even when it loses some access to magnification. A subclass of SCIContentView could be included for applications that want to adapt to different systems.

Neil

[Mike Lischke]

What's interesting is that I cannot reproduce any of these problems here and I have retina and non-retina displays attached to the MBP (retina built-in) and a mousewheel as well as a 2 touchpads (one internal and a magic trackpad). I don't set screen sizes to half pixel though (didn't know this is even possible and wonder what advantage it has to do so).

Post by Neil Hodgson
SCIContentView only implements scrollWheel to check for command+scroll magnification as it just calls super for all other cases. With a touch pad, pinch gestures work for magnify but some users will only have a mouse with a scroll wheel. This is difficult to work around. The majority of OS X users will now have touch pads, many will have retina displays, and few will only have scroll-wheel mice so greatest-happiness-for-the-greatest-number probably means fixing the display even when it loses some access to magnification. A subclass of SCIContentView could be included for applications that want to adapt to different systems.

I'm fine with removing command+scroll wheel for magnification as this is not a usual way to magnify content in the system and the pinch gestures works nicely.

Mike

[Neil Hodgson]

Post by Mike Lischke
What's interesting is that I cannot reproduce any of these problems here and I have retina and non-retina displays attached to the MBP (retina built-in) and a mousewheel as well as a 2 touchpads (one internal and a magic trackpad).

This is what it looks like:
Loading Image...

Neil

[Neil Hodgson]

Mouse wheel handling has been disabled using a preprocessor check. This change disables magnification by using the command key in conjunction with a mouse scroll wheel. Projects that want the old behaviour can #define SCROLL_WHEEL_MAGNIFICATION.

The modification does change scrolling behaviour: previously scroll gestures would almost always be treated as purely horizontal or purely vertical. Now, its more common for a horizontal scroll gesture to be interpreted as also scrolling vertically a little.

Change set:
https://sourceforge.net/p/scintilla/code/ci/8b997ba9d680d9125680eef43853029a0ee5a5e1/

Gah! After pushing the change set I noticed that this change has opted Scintilla into responsive scrolling.

While responsive scrolling is generally smoother, there can be some visual artefacts such as black or unchanging areas when scrolling is performed faster than Scintilla can prepare content.

There are also bugs where prepared areas are not invalidated when required. For example, open a C++ file and start a multi-line comment which continues off-screen. Scroll down and the comment style will not be apparent after a point, often terminating part way down a character.

Neil

[Neil Hodgson]

Post by Neil Hodgson
There are also bugs where prepared areas are not invalidated when required. For example, open a C++ file and start a multi-line comment which continues off-screen. Scroll down and the comment style will not be apparent after a point, often terminating part way down a character.

This appears to be fixed with
http://sourceforge.net/p/scintilla/code/ci/2f838e3e07254a053d6c118900fa13751ac77015/
which does not clip redraws to the window. Implemented by making RedrawRect and Redraw virtual with a Cocoa-specific implementation. This seems to be optimised well on OS X 10.9 but may be slower on older versions. Please report any notable performance problems as the code could be made conditional, checking for 10.9.

This issue was quite difficult to fix with the APIs provided for responsive scrolling appearing buggy - the preparedContentRect property returned an area that did not include all of the cached images. The recommended methods for clearing the cache - setting preparedContentRect to visibleRect did not appear to work. I came close to simply opting out of responsive scrolling.

Neil

[Chinh Nguyen]

FWIW, I had to disable scroll wheel magnification support for unrelated
reasons. What would happen is that if I used the scroll wheel and then
pressed cmd-W to close the editor while the text was still scrolling (due
to kinetic scrolling), the text would zoom in or out depending on the
direction of the scroll. The magnification is a saved preference for my
editor so the next editor that would be opened would be heavily zoomed in
or out. I already support cmd-+ and cmd-- for zooming in/out so it was no
big loss.

Post by Neil Hodgson
If the scrollWheel: method on SCIContentView is removed, the garbage
lines are not seen. Cocoa is doing something unusual here: simply calling
[super scrollWheel:] unconditionally does not fix it, so I expect Cocoa is
testing whether the class implements scrollWheel: and running a different
code path. This is probably caused by 10.9 responsive scrolling changes but
I don’t have an installation of 10.8 with a retina display to check.
SCIContentView only implements scrollWheel to check for command+scroll
magnification as it just calls super for all other cases. With a touch pad,
pinch gestures work for magnify but some users will only have a mouse with
a scroll wheel. This is difficult to work around. The majority of OS X
users will now have touch pads, many will have retina displays, and few
will only have scroll-wheel mice so
greatest-happiness-for-the-greatest-number probably means fixing the
display even when it loses some access to magnification. A subclass of
SCIContentView could be included for applications that want to adapt to
different systems.
Neil

[Chinh Nguyen]

I've had a user complain that they'll sometimes see a "barcode-like
pattern" for half a second while highlighting ever since they upgraded to
Mavericks. They're on a non-retina MBP but I haven't been able to
reproduce it.

Also, I'm still running 10.8 on my rMBP if you need me to look at anything.
I'm stuck on Xcode 4.6 because I use Intel's compiler for OpenMP support
and their latest version that's compatible with Xcode 5 is buggy.

Post by Neil Hodgson

Post by Neil Hodgson
There is an intermittent bug when scrolling up above the file start

with bounce, displaying garbage streaks that look like repetitions of some
pixel lines. Can’t reproduce it now.
Haven’t been able to reproduce that problem but have a new one: thin
vertical lines appear when scrolling horizontally towards the start of the
line. More likely to appear when scrolling slowly. This may be due to the
scroll view moving in screen pixel amounts instead of logical pixels
leading to ‘half pixel’ debris.
Neil