Forum Posts Feed
New app, Bike
< Next Topic | Back to topic list | Previous Topic >
Pages: ‹ First < 2 3 4 5 6 7 8 9 10 >
Posted by MadaboutDana
May 20, 2022 at 11:58 AM
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.
Posted by MadaboutDana
May 20, 2022 at 12:45 PM
Ah, see, that confirms the OS-specific thing. I’ve just taken a couple of moments to test Bear, iaWriter and Nota.
On my M1 machine, they’re all more or less as fast as each other, even when I resize windows and enter new text half/three-quarters of the way down the file. No problems with iaWriter, nor with Nota (which is in beta in any case, but seems to run very nicely). There was a very, very slight delay when I first started typing text into iaWriter about three quarters of the way down the “book”, but it didn’t last and there were no further delays during the actual typing. The initial pause certainly wasn’t long enough to cause any kind of awkwardness (maybe half a second). As you say, Bear was astonishingly fast – no sign of any pause whatsoever. But then, so was Nota.
I guess one of the big questions for Mac owners nowadays is just how long it will take before Intel-based machines cease being supported. I fear it’s a kind of attritional process – after all, developers have no real incentive to keep updating their apps for both platforms; sooner or later they’re going to focus on Apple Silicon. And Intel machines, alas, don’t have the virtual resources which the M1 machines are capable of using to emulate an Intel environment.
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.
Posted by satis
Nov 25, 2022 at 11:34 PM
Jesse is running a special for Bike - post a picture of your hometown in response to this Mastodon post and he’ll direct message you a coupon code to get Bike for $10 instead of the normal $30.
https://mastodon.social/@jessegrosjean/109404581663032742
Posted by Amontillado
Nov 29, 2022 at 02:56 AM
I took Jesse up on his ten dollar offer. First impressions are very positive. I haven’t tried the long file scroll test. For outline-sized files, it’s working fine.
I’m hoping to replace OmniOutliner. It’s great, but it’s got quirks and OmniGroup is not going to be addressing them soon, if ever. I’m sure it will be supported for a long time. It’s not exactly a vibrant product any more, though.
I think my primary use for it will be in conjunction with Devonthink. I’ll write snippets that cover an idea in DT and then link topics in Bike to them. I’ve been brainstorming this way with MindNode. MindNode is nice and can be used in outline mode, but it’s not quite the right tool for outlining.
The advantage to using an outline or a mind map as an overview of Devonthink topics is that I can discard an outline without discarding the ideas. Or, I can work up an alternate outline, recycling ideas.
The same could be done in Obsidian. Unfortunately, I seem to be a Devonthink recidivist. The tagging, replicants, and things like that just keep sucking me in.
Bike’s formatting popover is really cool. I will probably create links with Keyboard Maestro more often than manually, though.
If I highlight a word in Bike, go to Devonthink and pick an item, my new Link to Bike macro will copy the DT item link and either paste it as a new link or replace the one that’s already highlighted.
By the way, links that are just text with a separate link button is really nice for this sort of thing. There might be an argument for the link button taking up space, but the benefits are great. The text is more naturally editable.
Bike is a very nice tool.