###############################
Reducing the Geometry Bandwidth
###############################

Generally speaking, if we use more memory to store some geometrical attributes, we can expect a longer rendering time than if we were using less memory. This is true if:

    * We do enforce a 4 bytes alignment of the stored geometry channels, for each channel,
    * We do use equally fast data formats (in a word: don't use ``RED::MFT_DOUBLE``).

A practical example of this is detailed in the doc :doc:`/book/subjects/bk_ap/bk_ap_memory_usage` within the **Reducing Data Memory on the GPU** section. Using ``RED::MFT_UBYTE`` normals instead of ``RED::MFT_FLOAT`` normals can significantly improve the rendering speed on large assemblies. First this will improve the scalability of the system (we can load more data); second a given set of data requires less memory to be fetched by the GPU.

.. note:: 
    
    Depending on the GPU and on the actual performance bottleneck, this may be noticeable or not... A GPU that has no shader processing power may be bound by the size of the programs to process, so the bandwidth saving may remain unseen. Situations may vary a lot depending on the used platform. But generally speaking, reducing the number of geometry channels and the size of these channels set into ``RED::IMeshShape`` objects can be beneficial to performances, assuming we enforce proper memory alignment.
