[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile
- From: "leavengood" <trac@xxxxxxxxxxxx>
- Date: Thu, 01 Mar 2012 18:29:07 -0000
#8007: [app_server] fully unresponsive when resizing window of big textfile
-----------------------------+----------------------------
Reporter: ttcoder | Owner: axeld
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: System/Kernel | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking: 7882, 8136
Has a Patch: 0 | Platform: All
-----------------------------+----------------------------
Comment (by leavengood):
Replying to [comment:17 ttcoder]:
>
> In parallel I'm digging a little to find what kind of system resources
(ports..) are involved in this bug and thus could be the culprit. I've
been thinking of StyledEdit's BTextView (which is more in my area of
"expertise")... The hammering could be caused by the long lines "Soft
Wrap'ping" calculations. Except the bug does not occur on the initial file
opening with default window size, only when resizing the window (and soft
wrapping) to a larger size... Note to self: try to uncheck the "wrap long
lines" menu item and see if StyledEdit still freezes the system.
I'm sure it is the Soft Wrapping which is the main cause of this problem
from the StyledEdit side. As you probably know the whole layout needs to
be recalculated whenever the window is resized, and even if the length of
each line was cached (which might still be worthwhile) each line still
needs to be looked at to find a space to wrap on. And since each line
affects the one below it, all lines need to be considered when the window
is resized.
While again the core problem in this issue should be fixed, I would think
it should be possible to optimize the StyledEdit resizing somewhat. For
example if only the height changes, there is no need to recalculate the
layout, just show more text in the view. And in the case where the width
changes, to update what is shown it only really needs to recalculate the
layout from the start of the document to the view position (though I guess
the total height needs to be known to properly size the scroll thumb.) But
the whole thing should probably be done in a lower priority background
thread either way.
And while it will consume memory (and even more for a large document)
caching the line lengths would certainly save a lot of messaging with
app_server on resize. Of course then there is the line heights. But if the
document isn't styled it should be possible to just cache the line height
of the font being used and use that for all lines.
Anyhow these might be some nice improvements, since I think even for small
files the StyledEdit resizing isn't a great performer. But in general for
large file editing the editor needs to be specifically coded for that use
case: to not load the whole file in memory, not wrap lines, etc.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:31>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
