I was using R (www.r-project.org) to analyze data. When I resized the window, the spinner spins while the entire contents of the window buffer is rearranged. The causes significant delays depending on the amount of data in the buffer (>60 minutes and still waiting).
Analysis of spindump data shows, "Looks the app is not using non-contiguous layout. It's an app adoption issue."
The report is very, very vague - you are talking about Terminal (in which case you would have to take it up with Apple as they wrote that program) but also "Application Window" - what is that supposed to be? Are you using R in the Terminal or the R.app GUI? Please be more specific as of what you are doing - what buffer are you taking about? What are you opening where? Data is not opened in any buffer, it is loaded into R's memory as e.g. data frames so there is no "window" involved in that. If you are using the GUI, what exactly is the window that you're resizing (console, text editor, data editor, ..). Please consider reading the FAQ about reporting bugs are describe a reproducible example.
Apple looked at the problem (radar 12021659) and based on the analysis by the Terminal team that this problem arose because R "is not using non-contiguous layout. It's an [R] adoption issue." They concluded that it is not a Terminal issue.
The problem is easily reproduced by repeatedly printing a large dataframe. Normally, resizing the window is very fast; eventually, resizing the window will take a very long time (forever???). There seems to be a critical point in the amount of data that the window can hold before resizing becomes pathological rather than very fast.
Conclusion: R should be using non-contiguous layout to avoid this problem.
You did not answer a single of the questions so you report is as useless as before. Unless you intend to actually report something I'm going to close it.
1. I am not talking about terminal. I am talking about the console window.
2. Apple diagnosed this as an R problem based on an analysis of spindump data.
3. From a system point of view R is an application that runs on an operating system. In this case, the application (R) opens a terminal window.
4. The R Console is a window through which a user inputs R directives. You did not repeatedly print a large dataframe in the text editor, the data editor, etc. The contents of a large dataframe are repeatedly printed in the R Console. Eventually, when the R Console is resized, R takes forever to resize the console.
5. The diagnosis of the Terminal Team at Apple is that the app [R] is not using non-contiguous layout. They concluded that the problem is not an Apple problem. The problem is with the way that R is using libraries provided by Apple.
6. The problem is easily reproduced by following instructions: "reproduced by repeatedly printing a large dataframe. Normally, resizing the window is very fast; eventually, resizing the window will take a very long time (forever???). There seems to be a critical point in the amount of data that the window can hold before resizing becomes pathological rather than very fast."
Ok, we're slowly getting somewhere although not quite there yet - what do you mean by "printing a large dataframe" (many rows? columns? how many? what kind of values?) and what do you mean by "repeatedly"? (twice ... hundred times?) I can only keep repeating the same - provide a reproducible example (i.e. something that can be pasted into R to reproduce the problem) - again, please do read the FAQ.
Definition of repeatedly: "over and over, often, frequently, many times, again and again, time and (time) again, time after time, many a time and oft (archaic or poetic)."
Sample dataframe (names altered):
'data.frame': 4225527 obs. of 9 variables:
$ time : POSIXlt, format: (19 chars)
$ f1 : num (9 chars)
$ f2 : num (10 chars)
$ f3 : num (10 chars)
$ f4 : Factor w/ 1 level (13 chars)
$ f5 : Factor w/ 31 levels (14 chars)
$ f6 : Factor w/ 36 levels (8 chars)
$ f7 : num (9 chars)
$ f8 : Factor w/ 20 levels (5 chars)
I would guess 25-50 times.