Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I have no experience in developing iPad applications but I do have some in optimizing video games. So, I cannot give an exact answer but I want to give some tips in optimization.</p> <blockquote> <p><strong>Do not guess. Profile it.</strong></p> </blockquote> <p>It seems you are trying to make changes without profiling the code. Changing some suspicious code and crossing your fingers does not really work. You should profile your code by examining how <code>long</code> each task takes and how <code>often</code> they need to run. Try to break down your tasks and put profiling code to measure <code>time</code> and <code>frequency</code>. It's even better if you can measure how much <code>memory</code> are used for each task, or how many other system resources. Find your bottleneck based an evidence, not your feeling. </p> <p>For your specific problem, you think the program gets really slow when your resizing work kicks in. But, are you sure? It could be something else. We don't know for sure until we have actual profiling data.</p> <blockquote> <p><strong>Minimize problematic area and measure real performance before making changes.</strong></p> </blockquote> <p>After profiling, you have a candidate for your bottleneck. If you can still split the cause to several small tasks, do it and go to profile them until you cannot split it anymore. Then, try to measure their precise performance by running them repeatedly like a few thousand times. This is important because you need to know the performance (speed &amp; space) before making any changes so that you can compare it to future changes.</p> <p>For your specific problem, if resizing is really the issue, try to examine how it performs. How long it takes to perform one resize call? How often you need to do resize work to complete your job? </p> <blockquote> <p><strong>Improve it. How? It depends.</strong></p> </blockquote> <p>Now, you have the problematic code block and its current performance. You now have to improve it. How? well, it really depends on what the problem is. you could search for <code>better algorithms</code>, you could do <code>lazy fetching</code> if you can delay calculations until you really need to perform, or you could do <code>over-eager evaluation</code> by caching some data if you are doing the same operation too frequently. The better you know the cause, the easier you can improve it. </p> <p>For your specific problem, it might be just the limit of OS ui function. Usually, resizing button is not just resizing button itself but it also <code>invalidates</code> a whole area or its parent widget so that every ui stuff can be rendered properly. Resizing button could be expensive and if that's the case, you could resolve the issue by simply using image-based approach instead of OS ui-based system. You could try to use OpenGL if image operations from OS API are not enough. But, again, we don't know until we actually try them out and <code>profile</code> these alternatives. Good luck! :)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload