New app, Bike

Posted by steveylang
Dec 1, 2022 at 07:34 PM

LOL, this reminds me that I still have a Moby Dick MD file (1.2MB) that I used for similar testing. No fancy formatting other than headings for the titles.

It opens, reflows, and edits lickety-split on my iPhone XS Max (and of course my M1 MBA) with no discernible lag.

I second the kudos for FoldingText, I still use it as well. It handles Moby Dick very well too on M1, although a proper test for an M1 would probably be 20 Moby Dicks in a single file with inline images, tags, code blocks, and I don’t know what else.

MadaboutDana wrote:
Interesting, Jesse, thanks for the feedback. I’d be happy to run these
>tests again – it’s perfectly true that actually editing the
>middle of a very large document separates the sheep from the goats.
> >However, given the difference between the performance of my i7 MacBook
>Pro (now, alas, defunct) and the new M1-powered Mac, I do wonder if
>processing speed – but above all, OS optimisation – also
>makes a difference here. I’ll check it out.
> >By the way: loved/still love FoldingText. Please, please refocus,
>produce equally nifty iOS app, make large fortune from outlinersoftware
>forum members ;-)
> >Cheers,
>Bill
> >Jesse Grosjean wrote:
>>And just for a laugh, I opened the markdown version of the file (1.2 MB
>>>in size) in various markdown apps. Here’s how they all did:
>>>
>>> ...
>>>
>>>Now granted I’m running these apps on a new MacBook Pro 14
>>
>>This is interesting, but not my experience at all.
>>
>>I’m on a 2015 iMac 27, maybe that’s making a big difference, but
>>generally it still feels very fast.
>>
>>I think you may not be doing the full set of tests…
>>
>>Scrolling top to bottom, yes most apps can handle that OK. This is
>>because it gives the text system time pre-render and pre-layout. Same
>>thing if you resize the window or edit at the start of the document.
>>
>>The problem, in my experience, comes when you scroll down into the
>>middle of the document and try things. I’ve just retested (macOS
>12.3.1)
>>and I still see major problems:
>>
>>1. Bear (good) – Best that I tested. I think they might also be
>>using a custom built text view. Maybe it doesn’t matter for your
>>use-case, but I can’t figure out how to really resize the window text
>>dynamically. Line width is fixed. Yes you can change global preference,
>>but that’s not really what I mean when I say resize window. Also if you
>>do change that global preference while viewing test file you’ll find it
>>very slow to update. Anyway I would say Bear passes test well, but its
>>text presentation is less flexible them I would like for a text editor.
>>
>>2. ia Writer. I scroll half way down… I resize the window: It’s very
>>rough, screen only updates maybe once a second. I type: There’s a
>>noticeable delay. I type and there’s a noticeable delay. I don’t think
>>it passes, but it’s better the next apps (for this particular test)
>>
>>3. Nota. I start wonder if we are doing the same tests. Forget window
>>resize (which is the hard thing) if I type in the middle of a nota Moby
>>Dick document it takes multiple seconds before any text shows up.
>>
>>4. Taio. Same story as nota. Typing is pretty much impossible in the
>>middle of the document.
>>
>>I encourage a couple of other people to try these tests. Maybe my
>>computer really is just to slow, but I know when I do these things in
>>Bike on my computer things are instant.
>>
>>Generally I use TextEdit to compare Bike against the default text
>>system. It performs better than the listed apps that I’ve tried (except
>>for Bear), but still has major problems. For example scroll to middle
>of
>>test document and resize window. For me that often loses my place. The
>>window resize also effects scroll position and I’m lost. Or other times
>>it saves my place, until the first time I click anyway to place my
>>cursor, then it scrolls off into nowhere land.
>>
>>> You don’t have to slim own your app to the
>>> point of having no real features at all to benefit
>>> from fast loading and scrolling (and editing, for that matter).
>>
>>Bikes editor speed is independent from feature design choices.
>>
>>> So what’s his point? In short, what’s the point of Bike (I’ve got
>some
>>very
>>>large outlines in Dynalist, and they don’t slow down noticeably in any
>>>of the apps – even though they’re markdown-compatible)?
>>
>>My point is that I think outliners and text editors can be better than
>>they are. So I try to imagine it and then I try to build it.