I’ve found that in most cases, new features that would probably be held for major version releases (e.g., “this is a feature that would entice you to pay for the upgrade”) just come out when they’re ready it’s essentially shifting the app to a rolling release model. While I’m sympathetic to that, I’ve (somewhat) come around on the notion of “subscription apps” if the developers are responsible with it. If they really are a problem and you are on battery then you can turn off animations in preferences. I don't think the animations are expensive, but it's hard to test because that work happens in Mac OS window server and I'm not an expert there. On the other hand resize is instant and only does work for visible text in Bike. And then after that resize there's lots of background processing to refill a bunch of layout caches I guess. If you open a large document in TextEdit you will see that resize is quite slow and processor and memory intensive. So you pay for that cache and you also pay for the background processing required by pre-rendering.Īlso consider simple things like window resize. For most macOS apps scrolling performance is achieved by pre-rendering before and after the visible scroll area. This means you only pay memory for visible text. In Bike it's fast enough that when you scroll it just updates what you can see on the screen. I think the architecture needed to support them means the total package is less than most apps. Already probably fast enough for 99% of use cases as is. That will be fun, but not sure it’s actually needed. Eventually I may change to augmented b+tree and then should be able to work with gigabytes worth of outline. This is Bike’s performance bottleneck for large outlines. I’m using OrderedDictionary from Swift Collections to store rows. View implementation requires that each row has a unique ID. Each row has a `level` property, outline structure is determined dynamically. Model representation is interesting in that it’s just a flat list of rows. View performance is determined by visible text, not document size.Animations are performed by Core animation and Motion lib.I test performance using the Moby Dick Workout. Architecture needed to support fluid editing also makes Bike faster/more scalable than most (all?) outliners and many text editors.Javascript plugin API also expected in future, though no timing on that. bike file format is HTML subset, so files are easy to parse and manipulate. In outline mode rows are constrained to outline hierarchy. In text mode Bike works like a normal text editor.(movie on home page if you don't have Mac) Lots of text editors have animated some interactions (cursor movement, insert newline, etc), but I think Bike is the first designed from the ground up to support fluid editing. Bike’s most original feature is the “fluid” text editing.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |