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?
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
