BitTorrent (Protocol)

BitTorrent is a protocol designed for transferring files. It is peer-to-peer in nature, as users connect to each other directly to send and receive portions of the file.

BitTorrent is a method of distributing large amounts of data widely without the original distributor incurring the entire costs of hardware, hosting, and bandwidth resources.

However, there is a central server (called a tracker) which coordinates the action of all such peers. The tracker only manages connections, it does not have any knowledge of the contents of the files being distributed, and therefore a large number of users can be supported with relatively limited tracker bandwidth. The key philosophy of BitTorrent is that users should upload (transmit outbound) at the same time they are downloading (receiving inbound.) In this manner, network bandwidth is utilized as efficiently as possible. BitTorrent is designed to work better as the number of people interested in a certain file increases, in contrast to other file transfer protocols.

Instead, when data is distributed using the BitTorrent protocol, each recipient supplies pieces of the data to newer recipients, reducing the cost and burden on any given individual source, providing redundancy against system problems, and reducing dependence on the original distributor.

The most common method by which files are transferred on the Internet is the client-server model. A central server sends the entire file to each client that requests it -- this is how both http and ftp work. The clients only speak to the server, and never to each other. The main advantages of this method are that it's simple to set up, and the files are usually always available since the servers tend to be dedicated to the task of serving, and are always on and connected to the Internet. However, this model has a significant problem with files that are large or very popular, or both.

Namely, it takes a great deal of bandwidth and server resources to distribute such a file, since the server must transmit the entire file to each client. Perhaps you may have tried to download a demo of a new game just released, or CD images of a new Linux distribution, and found that all the servers report "too many users," or there is a long queue that you have to wait through. The concept of mirrors partially addresses this shortcoming by distributing the load across multiple servers. But it requires a lot of coordination and effort to set up an efficient network of mirrors, and it's usually only feasible for the busiest of sites.

Another method of transferring files has become popular recently: the peer-to-peer network, systems such as Kazaa, eDonkey, Gnutella, Direct Connect, etc. In most of these networks, ordinary Internet users trade files by directly connecting one-to-one. The advantage here is that files can be shared without having access to a proper server, and because of this there is little accountability for the contents of the files. Hence, these networks tend to be very popular for illicit files such as music, movies, pirated software, etc. Typically, a downloader receives a file from a single source, however the newest version of some clients allow downloading a single file from multiple sources for higher speeds.

A BitTorrent client is any program that implements the BitTorrent protocol. Each client is capable of preparing, requesting, and transmitting any type of computer file over a network, using the protocol. A peer is any computer running an instance of a client.
To share a file or group of files, a peer first creates a small file called a "torrent" (e.g. MyFile.torrent). This file contains metadata about the files to be shared and about the tracker, the computer that coordinates the file distribution. Peers that want to download the file first obtain a torrent file for it, and connect to the specified tracker, which tells them from which other peers to download the pieces of the file.

Though both ultimately transfer files over a network, a BitTorrent download differs from a classic full-file HTTP request in several fundamental ways:

BitTorrent makes many small data requests over different TCP sockets, while web-browsers typically make a single HTTP GET request over a single TCP socket. BitTorrent downloads in a random or in a "rarest-first"[2] approach that ensures high availability, while HTTP downloads in a sequential manner. Taken together, these differences allow BitTorrent to achieve much lower cost, much higher redundancy, and much greater resistance to abuse or to "flash crowds" than a regular HTTP server. However, this protection comes at a cost: downloads can take time to rise to full speed because it may take time for enough peer connections to be established, and it takes time for a node to receive sufficient data to become an effective uploader. As such, a typical BitTorrent download will gradually rise to very high speeds, and then slowly fall back down toward the end of the download. This contrasts with an HTTP server that, while more vulnerable to overload and abuse, rises to full speed very quickly and maintains this speed throughout.

The Types of Caching in ASP.NET

Introduction
The main benefits of caching are performance-related: operations like accessing database information can be one of the most expensive operations of an ASP page's life cycle.

If the database information is fairly static, this database-information can be cached.

When information is cached, it stays cached either indefinitely, until some relative time, or until some absolute time. Most commonly, information is cached for a relative time frame. That is, our database information may be fairly static, updated just a few times a week. Therefore, we might want to invalidate the cache every other day, meaning every other day the cached content is rebuilt from the database.

Caching in classic ASP was a bit of a chore, it is quite easy in ASP.NET. There are a number of classes in the .NET Framework designed to aid with caching information. In this article, I will explain how .NET supports caching and explain in detail how to properly incorporate each supported method into Web-based applications.

Caching Options in ASP.NET
ASP.NET supports three types of caching for Web-based applications:
Page Level Caching (called Output Caching)
Page Fragment Caching (often called Partial-Page Output Caching)
Programmatic or Data Caching

Output Caching:
Caches the output from an entire page and returns it for future requests instead of re-executing the requested page.
Fragment Caching:
Caches just a part of a page which can then be reused even while other parts of the page are being dynamically generated.
Data Caching:
Programmatically caches arbitrary objects for later reuse without re-incurring the overhead of creating them.

In Detail:
Output Caching
Output caching is the simplest of the caching options offered by ASP.NET. It is useful when an entire page can be cached as a whole and is analogous to most of the caching solutions that were available under classic ASP. It takes a dynamically generated page and stores the HTML result right before it is sent to the client. Then it reuses this HTML for future requests bypassing the execution of the original code.

Telling ASP.NET to cache a page is extremely simple. You simply add the OutputCache directive to the page you wish to cache. <%@ OutputCache Duration="30" VaryByParam="none" %>
The resulting caching is similar to the caching done by browsers and proxy servers, but does have one extremely important difference... you can tell a page which parameters to the page will have an effect on the output and the caching engine will cache separate versions based on the parameters you specify. This is done using the VaryByParam attribute of the OutputCache directive.
This is illustrated by a very simple example of output caching.
OutputCache Duration="30" VaryByParam="test"
<%@ Page Language="C#" %><%@ Page Language="VB" %><%@ OutputCache Duration="30" VaryByParam="test" %><%= Now() %>
This piece of code will cache the result for 30 seconds. During that time, responses for all requests for the page will be served from the cache.

Fragment Caching
Sometimes it's not possible to cache an entire page. For example, many shopping sites like to greet their users by name. It wouldn't look very good if you went to a site and instead of using your name to greet you it used mine! In the past this often meant that caching wasn't a viable option for these pages. ASP.NET handles this by what they call fragment caching.

More often than not, it is impractical to cache entire pages. For example, you may have some content on your page that is fairly static, such as a listing of current inventory, but you may have other information, such as the user's shopping cart, or the current stock price of the company, that you wish to not be cached at all. Since Output Caching caches the HTML of the entire ASP.NET Web page, clearly Output Caching cannot be used for these scenarios: enter Partial-Page Output Caching.

Partial-Page Output Caching, or page fragment caching, allows specific regions of pages to be cached. ASP.NET provides a way to take advantage of this powerful technique, requiring that the part(s) of the page you wish to have cached appear in a User Control. One way to specify that the contents of a User Control should be cached is to supply an OutputCache directive at the top of the User Control. That's it! The content inside the User Control will now be cached for the specified period, while the ASP.NET Web page that contains the User Control will continue to serve dynamic content. (Note that for this you should not place an OutputCache directive in the ASP.NET Web page that contains the User Control - just inside of the User Control.)

Data Caching
This is the most powerful of the caching options available in ASP.NET. Using data caching you can programmatically cache anything you want for as long as you want. The caching system exposes itself in a dictionary type format meaning items are stored in name/value pairs. You cache an item under a certain name and then when you request that name you get the item back. It's similar to an array or even a simple variable.

In addition to just placing an object into the cache you can set all sorts of properties. The object can be set to expire at a fixed time and date, after a period of inactivity, or when a file or other object in the cache is changed.

The main thing to watch out for with data caching is that items you place in the cache are not guaranteed to be there when you want them back. While it does add some work (you always have to check your object exists after you retrieve it), this scavenging really is a good thing. It gives the caching engine the flexibility to dispose of things that aren't being used or dump parts of the cache if the system starts running out of memory.

Sometimes, more control over what gets cached is desired. ASP.NET provides this power and flexibility by providing a cache engine. Programmatic or data caching takes advantage of the .NET Runtime cache engine to store any data or object between responses. That is, you can store objects into a cache, similar to the storing of objects in Application scope in classic ASP. (As with classic ASP, do not store open database connections in the cache!)
Realize that this data cache is kept in memory and "lives" as long as the host application does. In other words, when the ASP.NET application using data caching is restarted, the cache is destroyed and recreated. Data Caching is almost as easy to use as Output Caching or Fragment caching: you simply interact with it as you would any simple dictionary object. To store a value in the cache, use syntax like this:

Cache["Nikky"] = bar; // C#

To retrieve a value, simply reverse the syntax like this:

bar = Cache["Nikky"]; // C#

Note that after you retrieve a cache value in the above manner you should first verify that the cache value is not null prior to doing something with the data. Since Data Caching uses an in-memory cache, there are times when cache elements may need to be evicted. That is, if there is not enough memory and you attempt to insert something new into the cache, something else has gotta go! The Data Cache engine does all of this scavenging for your behind the scenes, of course. However, don't forget that you should always check to ensure that the cache value is there before using it. This is fairly simply to do - just check to ensure that the value isn't null/Nothing. If it is, then you need to dynamically retrieve the object and restore it into the cache.

'A Leader Should Know How to Manage Failure'

(Former President of India APJ Abdul Kalam at Wharton India Economic forum , Philadelphia, March 22,2008)
Kalam was asked:
Could you give an example, from your own experience, of ' How Leaders Should Manage Failure' ?

Kalam answered it like that:
Let me tell you about my experience. In 1973 I became the project director of India's satellite launch vehicle program, commonly called the SLV-3. Our goal was to put India's "Rohini" satellite into orbit by 1980. I was given funds and human resources -- but was told clearly that by 1980 we had to launch the satellite into space. Thousands of people worked together in scientific and technical teams towards that goal.

By 1979 -- I think the month was August -- we thought we were ready. As the project director, I went to the control center for the launch. At four minutes before the satellite launch, the computer began to go through the checklist of items that needed to be checked. One minute later, the computer program put the launch on hold; the display showed that some control components were not in order. My experts -- I had four or five of them with me -- told me not to worry; they had done their calculations and there was enough reserve fuel. So I bypassed the computer, switched to manual mode, and launched the rocket. In the first stage, everything worked fine. In the second stage, a problem developed. Instead of the satellite going into orbit, the whole rocket system plunged into the Bay of Bengal. It was a big failure.
That day, the chairman of the Indian Space Research Organization, Prof. Satish Dhawan, had called a press conference. The launch was at 7:00 am, and the press conference -- where journalists from around the world were present -- was at 7:45 am at ISRO's satellite launch range in Sriharikota [in Andhra Pradesh in southern India]. Prof. Dhawan, the leader of the organization, conducted the press conference himself. He took responsibility for the failure -- he said that the team had worked very hard, but that it needed more technological support. He assured the media that in another year, the team would definitely succeed. Now, I was the project director, and it was my failure, but instead, he took responsibility for the failure as chairman of the organization.

The next year, in July 1980, we tried again to launch the satellite -- and this time we succeeded. The whole nation was jubilant. Again, there was a press conference. Prof. Dhawan called me aside and told me, "You conduct the press conference today." I learned a very important lesson that day. When failure occurred, the leader of the organization owned that failure. When success came, he gave it to his team.

The best management lesson I have learned did not come to me from reading a book; it came from that experience.

What is Sharepoint

Overview

A SharePoint page is built by combining the web parts into a web page, to be accessed using a browser. Any web editor supporting ASP.NET can be used for this purpose, even though Microsoft Office SharePoint Designer is the preferred editor. The extent of customization of the page depends on its design.

SharePoint is a web-based collaboration and document management platform from Microsoft. It can be used to host web sites which can be used to access shared workspaces and documents, as well as specialized applications such as wikis, blogs and many other forms of applications, from within a browser. SharePoint functionality is exposed as web parts, such as a task list, or discussion pane. These web parts are composed into web pages, which are then hosted in the SharePoint portal. SharePoint sites are actually ASP.NET applications, which are served using IIS and use a SQL Server database as data storage backend.The term 'SharePoint' is commonly used to refer to one of the following two products:Windows SharePoint Services (WSS) Microsoft Office SharePoint Server 2007 (MOSS) In addition, previous versions of this software used different names (SharePoint Portal Server for example) but are referred to as "SharePoint".The SharePoint family also includes the Microsoft Office SharePoint Designer (SPD).



WSS pages are ASP.NET applications, as such SharePoint web parts use the ASP.NET web parts infrastructure, and using the ASP.NET APIs, web parts can be written to extend the functionality of WSS. In terms of programmability, WSS exposes an API and object model to programmatically create and manage portals, workspaces and users. In contrast, the MOSS API is more geared towards automation of tasks and integration with other applications.[1] Both WSS and MOSS can use the web parts API to enhance the end user functionality. In addition, WSS document libraries can be exposed over ADO.NET connections to programmatically access the files and revisions in them.

At the web server level, WSS configures IIS to forward all requests, regardless of file and content types, to the ASP.NET session hosting the WSS web application, which either makes a certain revision of a certain file available from the database or takes other actions. Unlike regular ASP.NET applications, the .aspx which contains the WSS (and MOSS) application code, resides in SQL Server databases instead of the filesystem. As such, the regular ASP.NET runtime cannot process the file. Instead, WSS plugs a custom Virtual Path Provider component[2] into the ASP.NET pipeline, which fetches the .aspx files from the database for processing. With this feature, introduced with WSS 3.0, both the WSS application as well as the data it generates and manages, could be stored in a database.

The first version, called SharePoint Team Services (usually abbreviated to STS), was released at the same time as Office XP and was available as part of Microsoft FrontPage. STS could run on Windows 2000 Server or Windows XP.

Windows SharePoint Services 2.0 was marketed as an upgrade to SharePoint Team Services, but was in fact a completely redesigned application[citation needed]. SharePoint Team Services stored documents in ordinary file storage, keeping document metadata in a database. Windows SharePoint Services 2.0 on the other hand, stores both the document and the metadata in a database, and supports basic document versioning for items in Document Libraries. Service Pack 2 for WSS added support for SQL Server 2005 and the use of the .NET Framework 2.0.
Windows SharePoint Services 3.0 was released on November 16, 2006 as part of the Microsoft Office 2007 suite and Windows Server 2008. In fact, Windows Server 2008 supports a separate server role for SharePoint services. WSS 3.0 is built using .NET Framework 2.0 and .NET Framework 3.0 Windows Workflow Foundation to add workflow capabilities to the basic suite. By the beginning of 2007 WSS 3.0 was made available to the public. Windows 2000 Server is not supported by WSS 3.0, nor is SQL Server 2000.

The WSS 3.0 wiki allows RSS export of content and, when viewed in Internet Explorer, provides a WYSIWYG editor. As with MediaWiki, it produces hyperlinks with a double square bracket but unlike MediaWiki it uses HTML for markup. An enhanced wiki is available for SharePoint on Codeplex and is free to download and install.

SharePoint solves four main problems:
· It’s difficult to keep track of all the documents in even a small office
· Email isn’t a great way to share files
· We work all over the place
· It’s hard to create/maintain web sites on your own

SharePoint is a web-based collaboration and document management platform from Microsoft. It can be used to host web sites which can be used to access shared workspaces and documents, as well as specialized applications such as wikis, blogs and many other forms of applications, from within a browser. SharePoint functionality is exposed as web parts, such as a task list, or discussion pane. These web parts are composed into web pages, which are then hosted in the SharePoint portal. SharePoint sites are actually ASP.NET applications, which are served using IIS and use a SQL Server database as data storage backend.

The term 'SharePoint' is commonly used to refer to one of the following two products:
Windows SharePoint Services (WSS)
Microsoft Office SharePoint Server 2007 (MOSS)

In addition, previous versions of this software used different names (SharePoint Portal Server for example) but are referred to as "SharePoint".

The SharePoint family also includes the Microsoft Office SharePoint Designer (SPD)

The SharePoint Family

Windows SharePoint Services (WSS)
Windows SharePoint Services (WSS) is a free add-on to Windows Server. WSS offers the base collaborative infrastructure, supporting HTTP and HTTPS based editing of documents, as well as document organization in document libraries, version control capabilities, wikis, and blogs. It also includes end user functionality such as workflows, to-do lists, alerts and discussion boards, which are exposed as web parts to be embedded into SharePoint pages. WSS was previously known as SharePoint Team Services. Though workflows can be created for WSS in SharePoint Designer or VS.NET unlike with MOSS no workflows come installed out-of-the box.

Microsoft Search Server
Microsoft Search Server (MSS) is an enterprise search platform from Microsoft, based on the search capabilities of Microsoft Office SharePoint Server.[2] MSS shares its architectural underpinnings with the Windows Search platform for both the querying engine as well as the indexer. MOSS search provides the ability to search metadata attached to documents.
Microsoft Search Server has been made available as Search Server 2008, which was released on March 2008. A free version, Search Server Express 2008 is also available. The express edition features the same feature-set as the commercial edition, including no limitation on the number of files indexed; however, it is limited to a stand-alone installation and cannot be scaled out to a cluster.

Microsoft Office SharePoint Server (MOSS)
Microsoft Office SharePoint Server (MOSS) is a costed component of the Microsoft Office server suite. MOSS is built on top of WSS and adds more functionality to it, including better document management, enterprise search functionality, navigation features, RSS support, as well as features from Microsoft Content Management Server. The Enterprise edition of MOSS also includes features for business data analysis such as Excel Services and the Business Data Catalog. MOSS also provides integration with Microsoft Office applications, such as project management capabilities with Microsoft Project Server and the ability to expose Microsoft Office InfoPath forms via a browser.[4] It can also host specific libraries, such as PowerPoint Template Libraries provided the server components of the specific application are installed. MOSS was previously known as SharePoint Server and SharePoint Portal Server.

Microsoft SharePoint Designer (SPD)
Microsoft Office SharePoint Designer (SPD) is a WYSIWYG HTML editor, which is primarily aimed at designing SharePoint sites and end-user workflows for WSS sites. It shares its rendering engine with Microsoft Expression Web, its general web designing sibling, and Microsoft's Visual Studio 2008 IDE.

Windows SharePoint Services (WSS) or Windows SharePoint is the basic part of SharePoint, offering collaboration and document management functionality by means of web portals, by providing a centralized repository for shared documents, as well as browser-based management and administration of them. It allows creation of Document libraries, which are collections of files that can be shared for collaborative editing. SharePoint provides access control and revision control for documents in a library.

It also includes a collection of web parts, which are web widgets that can be embedded into web pages to provide a certain functionality. SharePoint includes web parts such as workspaces and dashboards, navigation tools, lists, alerts (including e-mail alerts), shared calendar, contact lists and discussion boards. It can be configured to return separate content for Intranet, Extranet and Internet locations. It uses a similar permissions model to Microsoft Windows, via groups of users. Active Directory groups can be added to SharePoint groups to easily tie in permissions. Alternatively, other authentication providers can be added through HTML Forms authentication.

Assemblies Overview (.NET, C# )

Environment: C#, .NET

What is Assembly in .NET?

An assembly is a file that is automatically generated by the compiler upon successful compilation of every .NET application. It can be either a Dynamic Link Library or an executable file. It is generated only once for an application and upon each subsequent compilation the assembly gets updated. The entire process will run in the background of your application; there is no need for you to learn deeply about assemblies. However, a basic knowledge about this topic will help you to understand the architecture behind a .NET application.

An Assembly contains Intermediate Language (IL) code, which is similar to Java byte code. In the .NET language, it consists of metadata. Metadata enumerates the features of every "type" inside the assembly or the binary. In addition to metadata, assemblies also have a special file called Manifest. It contains information about the current version of the assembly and other related information.

In .NET, there are two kinds of assemblies, such as Single file and Multi file. A single file assembly contains all the required information (IL, Metadata, and Manifest) in a single package. The majority of assemblies in .NET are made up of single file assemblies. Multi file assemblies are composed of numerous .NET binaries or modules and are generated for larger applications. One of the assemblies will contain a manifest and others will have IL and Metadata instructions.

The main benefit of Intermediate Language is its power to integrate with all NET languages. This is because all .NET languages produce the same IL code upon successful compilation; hence, they can interact with each other very easily.

However, .NET is not yet declared as a platform-independent language; efforts are on at Microsoft to achieve this objective.

As of today, .NET applications are equipped to run only on Windows.

An Assembly contains Intermediate Language (IL) code, which is similar to Java byte code. In the .NET language, it consists of metadata. Metadata enumerates the features of every "type" inside the assembly or the binary. In addition to metadata, assemblies also have a special file called Manifest. It contains information about the current version of the assembly and other related information.

In .NET, there are two kinds of assemblies, such as Single file and Multi file. A single file assembly contains all the required information (IL, Metadata, and Manifest) in a single package. The majority of assemblies in .NET are made up of single file assemblies. Multi file assemblies are composed of numerous .NET binaries or modules and are generated for larger applications. One of the assemblies will contain a manifest and others will have IL and Metadata instructions.

The main benefit of Intermediate Language is its power to integrate with all NET languages. This is because all .NET languages produce the same IL code upon successful compilation; hence, they can interact with each other very easily. However, .NET is not yet declared as a platform-independent language; efforts are on at Microsoft to achieve this objective. As of today, .NET applications are equipped to run only on Windows.

An assembly is a fundamental building block of any .NET Framework application. For example, when you build a simple C# application, Visual Studio creates an assembly in the form of a single portable executable (PE) file, specifically an EXE or DLL.

Assemblies contain metadata that describe their own internal version number and details of all the data and object types they contain. For more information see Assembly Manifest.

Assemblies are only loaded as they are required. If they are not used, they are not loaded. This means that assemblies can be an efficient way to manage resources in larger projects.

Assemblies can contain one or more modules. For example, larger projects may be planned in such a way that several individual developers work on separate modules, all coming together to create a single assembly. For more information on modules, see the topic How to: Build a Multifile Assembly.

Assemblies have the following properties:

Assemblies are implemented as .exe or .dll files.

You can share an assembly between applications by placing it in the Global Assembly Cache.

Assemblies must be strong-named before they can be placed in the Global Assembly Cache. For more information, see Strong-Named Assemblies.

Assemblies are only loaded into memory if they are required.

You can programmatically obtain information about an assembly using reflection. For more information, see the topic Reflection.

If you want to load an assembly only to inspect it, use a method such as ReflectionOnlyLoadFrom.

You can use two versions of the same assembly in a single application. For more information, see extern alias.

Strong-Named Assemblies

A strong name consists of the assembly's identity—its simple text name, version number, and culture information (if provided)—plus a public key and a digital signature. It is generated from an assembly file (the file that contains the assembly manifest, which in turn contains the names and hashes of all the files that make up the assembly), using the corresponding private key. Microsoft® Visual Studio® .NET and other development tools provided in the .NET Framework SDK can assign strong names to an assembly. Assemblies with the same strong name are expected to be identical.

You can ensure that a name is globally unique by signing an assembly with a strong name. In particular, strong names satisfy the following requirements:

Strong names guarantee name uniqueness by relying on unique key pairs. No one can generate the same assembly name that you can, because an assembly generated with one private key has a different name than an assembly generated with another private key.

Strong names protect the version lineage of an assembly. A strong name can ensure that no one can produce a subsequent version of your assembly. Users can be sure that a version of the assembly they are loading comes from the same publisher that created the version the application was built with.

Strong names provide a strong integrity check. Passing the .NET Framework security checks guarantees that the contents of the assembly have not been changed since it was built. Note, however, that strong names in and of themselves do not imply a level of trust like that provided, for example, by a digital signature and supporting certificate.

When you reference a strong-named assembly, you expect to get certain benefits, such as versioning and naming protection. If the strong-named assembly then references an assembly with a simple name, which does not have these benefits, you lose the benefits you would derive from using a strong-named assembly and revert to DLL conflicts. Therefore, strong-named assemblies can only reference other strong-named assemblies.

A Kiss of Love

A married couple was in a terrible accident where the man's face was severely burned.

The doctor told the husband that they couldn't graft any skin from his body Because he was too skinny. So the wife offered to some of her own skin.

However, the only skin on her body , that the doctor felt was suitable would have to come From her buttocks. The husband and wife agreed that they would tell no one about where the skin came from, and they requested that the doctor also honor their secret.

After All, this was a very delicate matter.

After the surgery was completed, everyone was astounded at the man's new face. He looked more handsome than he ever had before!

All friends and relatives just went on and on about his youthful Beauty! One day, he was alone with his wife, and he overcome with emotion at her sacrifice.

He said, "Dear, I just want to thank you for everything you did for me.
How can I possibly repay you?


"My darling," she replied,

"I get all the thanks I need every time I see your mother Kiss you on your cheeks."

The Frame Buffer

Overview:

Rasterization generates a stream of source pixels from graphic primitives, which are combined with destination pixels in the frame buffer. The term frame buffer originates from the early days of raster graphics and referred to a bank of mem- ory that contained a single image, or frame. As computer graphics evolved, the term came to encompass the image data as well as any ancilliary data needed during graphic rendering.

In Direct3D, the frame buffer encompasses the currently selected render target surface and depth/stencil surfaces. If mul- tisampling is used, additional memory is required but is not explicitly exposed as directly manipulable surfaces.

After rasterization, each source pixel contains an RGB color, an associated transparency value in its alpha channel, and an associated depth in the scene in its Z value. The Z value is a ¯xed-point precision quantity produced by rasterization. Fog may then be applied to the pixel before it is incorporated into the render target. The application of fog mixes the pixel's color value, but not its alpha vlaue, from rasterization with a fog color based on a function of the pixel's depth in the scene.

Fog, also referred to as depth cueing, can be used to diminish the intensity of an object as it recedes from the camera, placing more emphasis on objects closer to the viewer.

After fog application, pixels can be rejected on the basis of their trans- parency, their depth in the scene, or by stenciling operations. Stencil operations allow arbitrary regions of the frame buffer to be masked away from rendering, among other things. Unlike the associated alpha and depth produced for each pixel during rasterization, the stencil value associated with the source pixel is obtained from a render state.

Double buffering is a concept you need to be familiar with before moving on. When data goes through the rendering pipeline, it does not exit the other end to you screen. As you know, the rendering pipeline takes in 3D data, and outputs pixels. These pixels are outputted to a rectangular grid of pixels, known as the “frame buffer”.

Eventually, the frame buffer is displayed on the monitor. Now the problem with this is that the displaying of the frame buffer to the monitor is not completely in your control. Imagine you want to draw a scene of a town with a few people roaming around. You need various different 3D models to create a believable town scene. A few buildings, some houses, some shops, different people models, maybe a few props like benches and lamp posts, and then the model of the ground to put all the stuff on. Now you’re happily sending data to your graphics card and everything is going fine, you send it house one, house two, the shop, a few people, but then before you can send in the data that represents another person, your graphics card decides to give the frame buffer to the monitor.

And what do you get on the screen?

You get a scene of a town that has a few people displayed, a few buildings, half a human (because the frame buffer was sent to the monitor before you finished sending the entire data for the human figure you were rendering) and no streets (because you haven’t sent that data in yet) or props.

This is obviously no good for business. So we need a way to counter this problem. This is where double buffering comes in. The trick is to have two frame buffers. One called the front buffer, and the second one called the back buffer.

The front buffer is the one that is always displayed on your screen, not the back buffer. The back buffer is used as the rectangular grid that the rendering pipeline outputs the pixels to. So all your rendering goes straight to the back buffer. Only when you tell D3D to move the back buffer to the front buffer will your scene be displayed on the monitor. And by the time you tell D3D to move the back buffer to the front, you would’ve already finished rendering the entire scene. So using the example above, when you are sending the data for the human 3D model and your system displays the frame buffer – instead of seeing an incomplete scene, you will see whatever is on the front buffer (which is nothing at this time).

Then you can continue rendering the rest of the scene to the back buffer and move the back buffer to the front buffer when you’re done.

The figure above shows this process. You keep on sending data through the pipeline and it outputs pixels to the back buffer at the other end. Only when you tell D3D to switch the buffers will D3D take the data that is in the back buffer and put it in the front buffer.

Depth Buffers :

This depth-buffer is also known as a z-buffer, because the z-axis usually represents “depth”. A depth buffer usually has a certain level of accuracy associated with it. Just like in C++ you can have a “float” data type which allows for 32 bits of floating-point precision, or you can have a “double” data type which allows for 64 bits of floating-point precision.

When we talk about “16” or “32” bits per pixel for a depth buffer, we are discussing the accuracy of the device for determining how to arrange our objects. The higher the bit depth, the more accurate this arrangement is. This accuracy can also come at a cost of performance though, so make sure you try to test the scene using both.