On 10/05/2014 12:32 PM John R Pierce wrote: > .... > the DDR3 on a Intel i5-4570 (random upper midrange cpu I picked) has > 25.6GB/sec memory bandwidth. a typical 1920x1080 display is 2Mpixels, > at 24 bit/pixel and 60Hz LCD refresh rate, thats 360MB/sec to refresh > the display. almost *nothing* compared with that 25GB/sec bandwidth. > lost in the noise (half of the .6, to be more specific). John and all, This can be seen as a good approach in that it suggests the kind of rational approach to making an evaluation toward purchase. But the example is a bit oversimplistic. (I'll not provide links to the below because this information can be found in text- and other sorts of books on programming, especially those on video programming.) The calculations John makes are valid as far as they go, valid for a screen with no applications/windows visible on it. Every time a window is opened onscreen not only must that window be painted on, but what was behind that window must be preserved in memory (in the even that window is closed). This applies to every window which is opened on that screen. Considering that there are often windows on top of windows on top of windows, we can see that there are layers upon layers of screen data which must be saved in memory and recallable at the click of a mouse. And not only must the screen data per se be stored in memory, but also its coordinates and "stack" position (which other windows and/or screen elements) it is "on top of" or "underneath". There are many other window properties which must be saved and recalled and then deleted to/from/to memory at appropriate times. (Consult a decent book on low-level X programming for some serious surprises.) Keeping track of all of this means that there is a lot of overhead in properly managing a display. Don't forget the cursor: as it moves about the screen it, the screen underneath it (composed of different either wholly or partially displayed windows, all stored in different parts of memory) must be constantly saved and restored. And for this to happen at all, the mouse must be constantly polled for input-- e.g., for movement, but also accompanying keyboard and mouse-button input-- and change shape accordingly. The cursor also changes shape as it moves over parts of the screen with different properties, stored in different parts of memory, requiring management overhead to determine which ones. Moreover, things happen within windows. Text might be updated, images changing, and videos running, even in windows not currently having the focus. Every time the user clicks on a dropdown or opens a child window within an application or cuts/copies and/or pastes text, screen data must be saved and managed. Apps like Firefox and Thunderbird, moreover, can have tabs, each of which is yet more screen data to store and manage. Now consider that with X we can have multiple viewports, what you might think of as desktops. The number of these is configurable, but I've often configured my display for four of them. (A long time ago I read that X was capable of handling 4 billion of them, at the time I though, "Pretty cool... more than one for each person on the planet".) Each of those can contain/entail everything mentioned above for a single viewport/desktop, possibly multiplying memory usage and processing by a factor of four. Lay on top of all of this that some people run virtual machines which can increase the need for video memory by yet another factor. In brief, a lot has to happen in addition to the simple rastorization of the screen that John describes, and so a video subsystem requires many times the amount of memory he suggests and number of discrete processor instructions his description would imply. Unless-- as could be the case-- there is some utility to assess/monitor all of these factors and output meaningful numbers, numbers which could be compared against similarly meaningful assessments/benchmarks of available video cards, we're left with anecdotal evidence which can vary widely from one user to another, for the same user from one day to another, even from one session to another. In addition, what a user does on his current system might not be the same as what he hopes to do or unexpectedly ends up doing on his next system, the system he's looking to purchase. Examples of anecdotal evidence might include: the user moves a window and, instead of the screen underneath it being instantly repainted as the window moves along, a gray trail is left in the wake of the window which may take some seconds to be filled in; or switching to an existing but hidden window (hidden under other windows), it takes a bit of time for the contents of that window to be painted in; a window initially resists moving after the user has grabbed it with the mouse pointer. These are all symptoms of a slow video subsystem; there are others, both more trivial and more serious-- and the sort of behavior I would think most users would want to avoid. Question (one among several): Wouldn't this kind of behavior be more likely to happen under a heavy system load-- say, upwards from 4.0 and even above 6.0-- when dedicated video hardware is lacking?