Jump to content

Performance issues in landscape


Ross Kimes

Recommended Posts

This is a combo bug report/feature request, but they are related so I figured I would post them together.

 

 

When using the 2-pane view in landscape (on either my iPhone 4 or iPad), the performance of adjusting the pane left or right is pretty bad (as opposed to the smooth transition of moving it up and down in portrait). I am guessing that this has to do with the fact that the text has to be redrawn to fit the changing width dimension. That does not happen in landscape because you are not changing the size of the contentView, just the frame around it.

 

I'm not sure if this would improve performance or not (don't know how it was programmed); but instead of listing the entire Bible in one big scroll view, I would recommend breaking it up into more manageable sections like chapters. There would not be near as much information to recalculate so I think it would be a lot smoother.

 

There would also be other navigation improvements that could be made if you switched to having less content in the scroll view, but I won't go into them now as this is the bug request section.

 

Thanks!

Ross

Link to comment
Share on other sites

This is a combo bug report/feature request, but they are related so I figured I would post them together.

 

 

When using the 2-pane view in landscape (on either my iPhone 4 or iPad), the performance of adjusting the pane left or right is pretty bad (as opposed to the smooth transition of moving it up and down in portrait). I am guessing that this has to do with the fact that the text has to be redrawn to fit the changing width dimension. That does not happen in landscape because you are not changing the size of the contentView, just the frame around it.

 

I'm not sure if this would improve performance or not (don't know how it was programmed); but instead of listing the entire Bible in one big scroll view, I would recommend breaking it up into more manageable sections like chapters. There would not be near as much information to recalculate so I think it would be a lot smoother.

 

There would also be other navigation improvements that could be made if you switched to having less content in the scroll view, but I won't go into them now as this is the bug request section.

 

Thanks!

Ross

I'm not sure I would call this a bug. But it is certainly an area that needs improvement.

 

We're well aware that the performance is "sluggish" when resizing the secondary pane in landscape. And you're right it's because we have to reflow the text when the horizontal width of the text content changes. Right now, even a single point change in the width triggers the text reflow calculation. We could certainly be smarter here. Only trigger the reflow during the drag if the width change crosses some threshold, only trigger the reflow when the drag is complete, etc. Just haven't had time to work on tuning this yet.

 

One thing I can assure you is that we don't load and render the entire contents of a module in the text scroll views. We only load a small portion around the visible "location" in the text. As the user scrolls we append (or prepend) content as needed. There is not enough physical memory or processor speed in these iOS devices to load and render the entire contents in one fell swoop.

 

We're using our own text display engine in the IOS application which is (nearly) identical to the one in the Mac application. We don't use the built in text view because it doesn't handle styled text. Hopefully, as time goes on, we'll be able to improve the text rendering speed.

 

Scott.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...