Jump to content


Photo

Performance issues in landscape


  • Please log in to reply
2 replies to this topic

#1 Ross Kimes

Ross Kimes

    Member

  • Members
  • Pip
  • 7 posts
  • Accordance Version:Non-user

Posted 27 January 2011 - 01:02 AM

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

#2 Scott Knapp

Scott Knapp

    Platinum

  • Accordance
  • 1,144 posts
  • Gender:Male
  • Location:Orlando, FL
  • Accordance Version:10.x

Posted 27 January 2011 - 11:18 AM

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.

#3 Ross Kimes

Ross Kimes

    Member

  • Members
  • Pip
  • 7 posts
  • Accordance Version:Non-user

Posted 27 January 2011 - 01:30 PM

Makes sense. Thank you for the detailed reply.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users