#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 ttcoder): Regarding optimizing the BTextView inside StyledEdit, The curious thing is, the layout is quite fast in the "standard window width" case: the first time you open the big textfile, it opens very quickly. If there is a way to adapt the piece of code handling standard width to the other case (or, if the ''same'' code handles both cases, find out why it over-performs so much in the initial case, compared to its poor performance in the resized-window case) then that would be promising: one could optimize the general resizing without embarking into big class architectural changes. On the priority inversion front, This is yet another case where I decided to start something and didn't go far -- never went beyond downloading the sources and marking with a /*XXXX*/ some of the functions that I understood were relevant from bonefish's pointers. I got myself a Core 2 duo 'puter now, and understand what all the rage is about in Haiku circles ;-) -- this thing indeed feels fast; got all the responsiveness I had in BeOS in the olden days and more! And TuneTracker-Haiku will ship on dual-CPU systems, or so I hear from Dane, so little incentive there either to make it single-CPU friendly. I feel for those using Haiku on older machines though. I guess there's less and less of those anyway. -- Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:33> Haiku <http://dev.haiku-os.org> Haiku - the operating system.