I'm experimenting with text annotation in CodeMirror.
What's the difference between using TextMarker and Mode?
It seems that both would be the job done, but the Mode API seems more complicated.
Are there significant performance improvements with Mode?
Yes, highlighting by a mode is computed on demand, whereas making all text in a document to have the right color requires you to do it yourself, and update it yourself whenever the document changes. For big documents, this is going to be very expensive.
Related
I have a Flutter app which is becoming more and more janky as time goes by and more features are added. Therefore, is there some utility to make it as smooth as 60FPS?
I know there are some official guides here: https://docs.flutter.dev/perf. However, I have tried to optimize and it is still slow. You know, some things just cannot be fast enough, such as long text, dynamic layout, necessary synchronous computations, etc. Especially when entering a new page or scrolling down a ListView. In addition, I have to use brainpower to find out what is slow and optimize when new features are added, so I hope there is some fully automatic thing which I can drop-in replace and forget it and it just works forever.
Disclaimer: I wrote this package and this is a Q&A style StackOverflow answer.
Yes, I have made it: https://github.com/fzyzcjy/flutter_smooth.
No matter how heavy the tree is to build/layout, it will run at (roughly) full FPS, feel smooth, has zero uncomfortable janks, with neglitable overhead. (I have made some benchmark reports here)
As for usage, for common scenarios, add 6 characters ("Smooth") - ListView becomes SmoothListView, MaterialPageRoute becomes SmoothMaterialPageRoute. For complex cases, use SmoothBuilder(builder: ...) and put whatever you want to be smooth inside the builder.
Roughly speaking about the implementation, it is done by submitting extra frames to the rasterizer every ~16ms, without disturbing all existing code. Therefore, the existing app code will almost not even know the existence of this package.
You need to check how do you use widgets, unnecessary rebuilds, some heavy operations when the widget is creating o rebuilding and it’s recommended to use the performance profiler in the devtools.
I've read in the documentation that the NSString category method drawInRect is good for small amounts of text, but is too much overhead for large amounts. The alternative in my case would be to use Core Text CTFrameDraw.
My question is, what is the "cut-off" point between using drawInRect vs Core Text? Is Core Text always faster than drawInRect? If the extra programming is not the issue, should I always just use Core Text instead of drawInRect, even for small strings?
Mostly I'll be drawing paragraphs, but sometimes they can be short lines too.
For me it comes to use core text when I have some specific requirements from the graphic designer. For instance label that need to mix colors, type, font size etc. drawRect is method that draws something in a view layer, is just a wrapper around CG functions, core text is full framework to deal on how to draw text: change fonts, spaces, interlines.
I mean is not fair as a comparison, a better question could be when it comes to use core text instead of common UI text porpoise obejects and the answer is based on your app design-UI related requirements. Hope this helps.
I would write some test code to benchmark the two methods under consideration using your expected statistical distribution of string content. Maybe a timing a few tens of millions of string renders using each. Run the benchmarks on an actual iOS device, as relative performance may be different using the ARM targeted frameworks.
I wonder if using a UIWebView would get all the performance that's possible. The iOS (and every OS) has a constantly loaded webkit ready to go. Its pretty well optimized too. It would also get work offloaded.
Interesting to compare.
I recently chose to switch to a method where my library is totally empty and I embed every image/animation/sound that I need via the Embed tag because it would make my life easier. Having a lot of symbols in my library causes CS5 to run extremely slowly and it was really annoying me.
This was totally fine for making games for computers but I'm currently working on my first iPhone game and I'm noticing that the game starts lagging after a few seconds of play. It's not even a complex game but it does have a lot of images with transparency. So I'm wondering if it would run faster if I forget about the empty library method. I don't really know how that would affect performance but this is the first time that I have to worry about performance. But I am aware of other things that affect performance like transparency and object pooling (just read about this one).
Also the exact same game runs worse on an iPad even though it's a more powerful device?
Having images in your library means that Flash will compress them when it exports the SWF/SWC. This may or may not be desirable.
Using the [Embed] tag means that you can compress them yourself in something like Photoshop and have complete control over the output.
You say that your "game starts lagging after a few seconds of play". This seems to be a memory/design problem rather than whether or not your images are embedded through code or as library symbols. Do some profiling to see where you're spending most of your time, and to check that you don't have a memory leak.
Both using the library and the [Embed] metatags influence performance of your IDE, but they are evaluated at compile time and will produce just about the same byte code.
The performance of your game at runtime is an entirely different issue, though you might be able to get good results by rethinking which images to embed as bitmaps and which to use as vector sprites, how to organize larger images (e.g. creating one basic player sprite and adding individual looks by composition, instead of making each player variation a full sized animation) and trying to reduce the use of transparency and alpha masks.
There are many good articles about improving ActionScript performance both on the AVM2 and on iOS devices. Try searching for "ActionScript optimization runtime" - it should yield plenty of results.
Aside from the WYSIWYG editor, what are the advantages of using XIB/NIB files over defining the layout in code in iPhone/iPad/iOS?
While I don't find XIB files much useful, many iOS developers do, which makes me suspect I might not know their benefits or how to use them properly.
Easier maintenance. More often than not, clients require last minute changes like changing the logo or changing colors or realigning something or some such. Much easier to change it in a xib file and see/show the results immediately
Decoupling. It forces you to write nicely decoupled code right from the offset, which again means easier maintenance.
Defining things in Interface Builder makes them much easier to adjust later. Also, doing interface elements in code can lead to a lot of code bloat, for setting things like exact placement, font, color, etc.
The main advantage using code directly gives you is speed. But it's usually better to start in IB and then see what might need speeding up.
Table cells are one of the main areas where you might consider drawing elements in code for speed.
Personnaly, I'm using XIB to see graphically my I'm doing so I don't have to run, check the look, change a bit the color, run the app, check... It allows me to get a better design. If you work with designer that gives you photoshop design, it will not be useful for you.
Second thing : when you start to really handle Xib, it's much faster than doing it with code (but it takes time and training for TableView and tableView cell for example)
my app asks the user yes-no questions, user replies using a uiswitch on screen. i've been thinking about creating a custom version of the switch that would display yes/no instead of on/off and would use a green/red background as an indicator of the value. after creating a mock up i'm not so sure this is the way to go. using the default switch doesn't feel right but so does changing it too much. what do you think?
It really depends; some custom applications have extremely custom UIs (such as ConvertBot, for example) and it works great for them. The risk is sometimes worth the effort. In other scenarios, custom widgets result in breaking usability. I don't think that changing 'ON/OFF' to 'YES/NO' is groundbreaking, if you do it right you can pull it off no problem.
I think if your mockup was better done (the slider should be divided into two to have YES AND NO of equal length with equal padding on both sides) it would look a little better.
From a user interface perspective, this is a bad idea. People have already learned the default switch, so why change it now?
Additionally, you run the risk of adding another source of bugs to your application that was not present before.
Depending on the app, this can be very valid. Sure people are used to the default controls, but changing the text or colors is not going to break the user's understanding of these controls. Its still the same switch underneath.
In your example you color both the Yes/No. That is the only concern I would have that you did change how the core switch works. Typically, it works with a highlighted color and a grey color. So, having it stay colored on both options could potentially be confusing.
Regardless, if you want to build your app this way, you should. Just because the iPhone offers great default controls doesn't mean developers shouldn't innovate and add their own or take the default controls to the next level.
Take a look at the custom UISwitch control that I built to allow me to change the background color of the control. You could use the same method to change the text, the font, or the text color very easily.
http://www.homick.com/posts/custom-uiswitch-control
The code is available on Github and includes a PSD that is used to build three different png files that the control uses. You can modify the contents of the psd to recreate the png files in whatever format you like. Swap those into the control and away you go.