bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen <aaronjensen@gmail.com>]

On Sun, Feb 2, 2020 at 2:30 PM Alan Third <alan@idiocy.org> wrote:
>
> On Sun, Feb 02, 2020 at 08:49:44AM -0800, Aaron Jensen wrote:
> > On Sun, Feb 2, 2020 at 5:42 AM Alan Third <alan@idiocy.org> wrote:
> > >
> > > Out of interest, is the mac port fast under the same conditions? Here
> > > their performance seems to be almost identical with the mac port only
> > > fractionally faster, and their performance scales similarly with frame
> > > size.
> >
> > For scrolling/full repaints the mac port is significantly faster,
> > similar to repaint speed of cursor moves. With the patch, Emacs 28's
> > full repaint when taking about 3/5s of my screen takes about 400ms
> > whereas it's about 16.7ms (60fps) with mac port. Emacs 27 seems to
> > paint even faster than that.
>
> Amazingly the attached patch is faster than the mac port on my machine
> (13" retina macbook pro) in the scroll test.
>
> I can’t see that holding for your screen, though.

Here are scroll test results in org.el:

28 with patch - 35s
27 - 4s
26 macport - 10.2s

Question--how are you compiling locally? Maybe there are optimization
flags that you're using that I'm not that's throwing off my
comparison.

I do this:

export PATH="/usr/local/opt/gnu-sed/libexec/gnubin:$PATH"
export LDFLAGS="-g
-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.13.sdk/usr/lib
-lxml2 -lz -lpthread -licucore"
export CFLAGS="-g -O0
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/libxml2
-I/usr/local/opt/imagemagick@6/include"
export CXXFLAGS="-g -O0"
./autogen.sh
./configure --enable-locallisppath=/usr/local/share/emacs/site-lisp \
            --infodir=$EMACS_DIR/share/info/emacs \
            --prefix=$EMACS_DIR \
            --without-makeinfo
make -j8

> So turns out you need to do some fancy‐pants manoeuvres to scale
> CGLayers correctly. They also appear to draw faster when correctly
> scaled, presumably because it’s not having to scale everything while
> drawing to the screen.

Nice.

> I know exactly what’s causing the glitching, but I’ll come back to
> this tomorrow.

Looking forward to hearing more.