Further 2.0 updates/improvements

This commit is contained in:
Anton Firszov 2022-02-07 17:10:47 +01:00 коммит произвёл GitHub
Родитель 0f23645f0f
Коммит 363d0cd4c5
Не найден ключ, соответствующий данной подписи
Идентификатор ключа GPG: 4AEE18F83AFDEB23
1 изменённых файлов: 1 добавлений и 1 удалений

Просмотреть файл

@ -3,7 +3,7 @@
### Why is @"SixLabors.ImageSharp.Image`1" a generic class? ### Why is @"SixLabors.ImageSharp.Image`1" a generic class?
We support multiple pixel formats just like _System.Drawing_ does. However, unlike their closed [PixelFormat](https://docs.microsoft.com/en-us/dotnet/api/system.drawing.imaging.pixelformat) enumeration, our solution is extensible. We support multiple pixel formats just like _System.Drawing_ does. However, unlike their closed [PixelFormat](https://docs.microsoft.com/en-us/dotnet/api/system.drawing.imaging.pixelformat) enumeration, our solution is extensible.
A pixel is basically a small value object (struct), describing the color at a given point according to a pixel model we call Pixel Format. `Image<TPixel>` represents a pixel graphic bitmap stored as a **generic, discontiguous memory block** of pixels, of total size `image.Width * image.Height`. Note that while the image memory should be considered discontiguous by default, if the image is small enough (less than ~4GB in memory, on 64-bit), it will be stored in a **single, continuous memory block** for improved performance. The reason why there is additional support for discontiguous buffers is to allow images at super high resolution, which couldn't otherwise be loaded due to limitations to the maximum size of objects in the .NET runtime, even on 64-bit systems. A pixel is basically a small value object (struct), describing the color at a given point according to a pixel model we call Pixel Format. `Image<TPixel>` represents a pixel graphic bitmap stored as a **generic, discontiguous memory block** of pixels, of total size `image.Width * image.Height`. Note that while the image memory should be considered discontiguous by default, if the image is small enough (less than ~4MB in memory, on 64-bit), it will be stored in a single, continuous memory block. Upon memory optimization advantages, discontigous buffers also enable us is to load images at super high resolution, which couldn't otherwise be loaded due to limitations to the maximum size of `Span<T>` in the .NET runtime, even on 64-bit systems. Please read the [Memory Management](memorymanagement.md) section for more information.
In the case of multi-frame images multiple bitmaps are stored in `image.Frames` as `ImageFrame<TPixel>` instances. In the case of multi-frame images multiple bitmaps are stored in `image.Frames` as `ImageFrame<TPixel>` instances.