New app, Bike

Posted by Jesse Grosjean
May 21, 2022 at 03:29 PM

>On my M1 machine, they’re all more or less as fast as each other…

I borrowed a M1 Mac (the first M1 MacBook Air) for testing.

Here’s my experience:

First everything (including Bike) is choppy to scroll. Not terrible, but not “like butter”, they are all missing frames. There are no big processes going on in background that I can see. I test for maybe 20 minutes, this behavior doesn’t change. I come back after MacBook has gone to sleep, and now Bike (and other apps to different extents) scroll like butter. I don’t know the cause, seems not directly related to Bike since it was effecting all apps.

—-

Now that the slowdown is gone…

TextEdit: Scroll half way down. Resize window, definitely a different codepath here, resize IS fast… BUT it’s also really buggy. I regularly get big blank areas in text view where there should be text when I resize. And after a resize clicking to place my cursor will reset the view position, for example: 1. Resize window. 2. (Assuming window hasn’t become blank from first bug) Click on the word “Whale”. 3. I end up in a different part of the document with “Whale” now scrolled off the screen. Resize is fast, but the above experiences are problematic to say the least.

iA Writer: Editing performance is better/good. Not as fast as Bike, but hard to notice delay. Window resize performance is still very slow, screen only updates every 0.5 to 1.0 sec or so. NOTE: Window resize test needs to be narrow enough that text wrap width is changing. Window resize is fast if text isn’t being forced to wrap.

Taio: Faster, but still not very useable. Scroll to middle of document. Resize window is still very chunky. Text editing is also delayed, though certainly faster then on my iMac.

Summary: M1 is faster, but underlying text systems still leave lots of room for improvement. I don’t understand how these tests could pass with a somewhat faster M1. I think maybe we are not doing the exact same tests. In particular text needs to wrap when you resize.

These tests might seem arbitrary. Why all the emphasis on scroll to the middle and resize text width? I think they are important to get right in any app, but essential to get right in an outliner. Anytime you zoom/focus/hoist you are performing this resize/scroll interaction.

With that in mind try Bike again with the Moby Dick document. Expand everything, use the Focus In / Focus Out shortcuts to navigate within the outline. Focusing into chapters or and individual items. It’s all smooth like butter. There are no breaks or pauses. It’s a different experience. This is why I built Bike and why I do the tests I do, because I’m trying to build this type of experience.

Also look at the amount of memory Bike is using, about the same as TextEdit. Look at the app download size, just a few MB. I’m trying to create something elegant and beautiful. Bike might not be the answer for you, but it’s unique and does things that no other app can do.

—-

So far all the reported Moby Dick tests have been with standard text editors, not outliners. Please use the .opml version to also test some outliners. Expand All, then navigate throughout the structure using Zoom/Focus/Hoist feature. Check RAM usage. I think you will see that Bike provides a unique experience.

Performance and fluid animations are just one aspect of what makes Bike unique. It’s unique in other fundamental ways. For example Bike also has a full text editor mode and a full outliner editor mode. This is a fundamental building block for future features. No other outliner offers this combination.

Bike has other good fundamentals like open file formats, read / write of file format (not just export), scripting, standard document based architecture. Not all unique features, but a rare combination.