#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: 1 | Platform: All -----------------------------+---------------------------- Comment (by Pete): I'm afraid it's not really working for me. I finally got to do a complete system build with the patch (number 4) applied, and have it as an alternate 'system' folder. When I first boot up with it, I notice improvement in things like the StyledEdit problem that started this ticket. I can resize the window at will without locking the system up. (The contents of the window still take a very long time to get redrawn, but the cursor remains responsive.) However, at some point something happens -- not quite sure what... I opened a terminal window to run 'top' amongst other things -- and the system locks solid again. Not sure if it would have freed up eventually; I gave up and rebooted. Similarly, Web+ initially doesn't seem to freeze the cursor, but eventually it goes back to its old ways. Maybe rather worse than with the standard build -- not sure. (It looks as if the freezes are associated with W+'s "offscreen" window, which seemed to show activity peaks in top's display at the same time. Bezilla typically does not freeze, though there is slight hesitation in the cursor when it is doing heavy window drawing.) Finally, I didn't find the hoped-for improvement in audio glitching. Moving a window still causes just as many 'crackles' as before, despite the supposed higher priority of audio. (This is again real-time audio. The media player with it's large buffer doesn't normally glitch.) -- Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:54> Haiku <http://dev.haiku-os.org> Haiku - the operating system.