[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile
- From: "ttcoder" <trac@xxxxxxxxxxxx>
- Date: Tue, 08 Nov 2011 09:51:08 -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: Servers/app_server | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
----------------------------------+----------------------------
Comment (by ttcoder):
@bonefish if you suspect a particular rev. to be the trigger of the
regression (or if a range of revs are candidate for bisecting) I can test
that here if you need. But in your latest comment it seems the suspicion
is not on a recent regression, but in mutex acquisition and thread
scheduling being "out of phase" with each other ? So a thread can make a
system call to acquire_sem(), and the kernel may grant that semaphore but
''not'' schedule the thread to work (and eventually release the sem)
immediately, hmmm. The kernel neophyte in me wonders, why not do it the
other way around: when the kernel schedules a given thread for running
(according to priority ..etc) at ''that'' time it also looks at what
system calls are pending for that thread, and grants it the resource.. (if
available, otherwise it goes on to next schedulable thread).
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.
More notes to self: when you have a million+ lines to soft-wrap in a
textfile, that must entail an awful lot of BView|BFont::StringWidth()
calls. These proably involve a ''synchronous'' round-trip to the
app_server, with a write_port() call, from within the B_DISPLAY_PRIORITY
window thread. Unless StyledEdit has a mechanism in place for caching
string lengths and avoiding such performance hits.. But given how its
performance degrades I guess it uses normal code. If this explanation
holds water, it'd mean a minimal test case to replicate the freeze would
look like (a more compilable version of) this:
{{{
BApplication app; // create link to app_server
BWindow win;
BView view;
win.AddChild( &view ); // make sure StringWidth() will round-trip to
app_server (maybe BWindow::Show() is a pre-requisite first?)
for( int i = 0; i<1000000; i++ )
{
float dummy = view.StringWidth( "is this string more thann 80 columns
and to be wrapped" );
}
}}}
In BTextView it seems that BFont::GetHeight() is [http://dev.haiku-
os.org/browser/haiku/trunk/src/kits/interface/TextView.cpp#L3884 called]
from within a very inner loop, should check if that implies a round-trip
to app_server... And [http://dev.haiku-
os.org/browser/haiku/trunk/src/kits/interface/TextView.cpp#L4187 here] is
an uncached StringWidth(), together with an ifdef'ed cached one, hmmm.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:17>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
