LINUX.ORG.RU

История изменений

Исправление Zubok, (текущая версия) :

Image ­— это структура X-клиента, а pixmap — это объект на стороне сервера X. В случае MIT-SHM, казалось бы, сервер X имеет доступ к клиентской картинке напрямую. Но есть два основных «но»:

1) В случае удаленного клиента у тебя неизбежно должен применяться обычный GetImage/PutImage, что приведет к перегонке картинки по сети туда-обратно. Это надо иметь в виду и использовать Images там, где они действительно эффективны. Например, если ты делаешь много битовых операций над изображением, то тогда правильнее делать это все в Image, а на сервер присылать обновления, чтобы отобразить. Нельзя рассматривать MIT-SHM как средство для использования Image как Pixmap. Его надо рассматривать только как технологию оптимизации в случае, если клиент и сервер находятся на одной машине.

2) Даже если Pixmap и разделяемая Image доступны серверу напрямую, есть важное отличие: операции с pixmap потенциально аппаратно ускорены, а с Image — нет. Pixmaps могут мигрировать между памятью CPU и GPU. Этой миграцией занимаются механизмы 2D ускорения, такие как EXA. Если у тебя pixmaps оказались в памяти GPU (то есть в offscreen memory), а они туда действительно набиваются, то операции копирования областей, например, будет выполнять GPU, если драйвер нормальный, конечно.

(II) EXA(0): Driver allocated offscreen pixmaps
(II) EXA(0): Driver registered support for the following operations:
(II)         Solid
(II)         Copy
(II)         Composite (RENDER acceleration)
(II)         UploadToScreen
(II)         DownloadFromScreen

Если ты используешь OpenGL, то там уже есть расширение, которое умеет Pixmaps преобразовывать в текстуры и манипулировать ими (GLX_EXT_texture_from_pixmap). XImage из разделяемой памяти не может мигрировать в память GPU по определению.

Вот, например, простая вводная: https://techbase.kde.org/Development/Tutorials/Graphics/Performance. Просто замени QPixmap на pixmap, а QImage на XImage. Разве только момент медленности преобразования чуть подправить, так как свои XImage ты можешь в удобном для pixmap формате держать. Тогда преобразования не нужно. Но в общем все так: преобразование Image в Drawable (pixmap или window) и назад - это дорогая операция с дичайшим roundtrip.

Исправление Zubok, :

Image ­— это структура X-клиента, а pixmap — это объект на стороне сервера X. В случае MIT-SHM, казалось бы, сервер X имеет доступ к клиентской картинке напрямую. Но есть два основных «но»:

1) В случае удаленного клиента у тебя неизбежно должен применяться обычный GetImage/PutImage, что приведет к перегонке картинки по сети туда-обратно. Это надо иметь в виду и использовать Images там, где они действительно эффективны. Например, если ты делаешь много битовых операций над изображением, то тогда правильнее делать это все в Image, а на сервер присылать обновления, чтобы отобразить. Нельзя рассматривать MIT-SHM как средство для использования Image как Pixmap. Его надо рассматривать только как технологию оптимизации в случае, если клиент и сервер находятся на одной машине.

2) Даже если Pixmap и разделяемая Image доступны серверу напрямую, есть важное отличие: операции с pixmap потенциально аппаратно ускорены, а с Image — нет. Pixmaps могут мигрировать между памятью CPU и GPU. Этой миграцией занимаются механизмы 2D ускорения, такие как EXA. Если у тебя pixmaps оказались в памяти GPU (то есть в offscreen memory), а они туда действительно набиваются, то операции копирования областей, например, будет выполнять GPU, если драйвер нормальный, конечно.

(II) EXA(0): Driver allocated offscreen pixmaps
(II) EXA(0): Driver registered support for the following operations:
(II)         Solid
(II)         Copy
(II)         Composite (RENDER acceleration)
(II)         UploadToScreen
(II)         DownloadFromScreen

Если ты используешь OpenGL, то там уже есть расширение, которое умеет Pixmaps преобразовывать в текстуры и манипулировать ими (GLX_EXT_texture_from_pixmap). XImage из разделяемой памяти не может мигрировать в память GPU по определению.

Вот, например, простая вводная: https://techbase.kde.org/Development/Tutorials/Graphics/Performance. Просто замени QPixmap на pixmap, а QImage на XImage. Разве только момент медленности преобразования чуть подправить, так как свои XImage ты можешь в удобном для pixmap формате держать. Тогда преобразования не нужно. Но в общем все так: преобразование Image в Drawable (pixmap или window) и назад - это дорогая операция с дичайшим round-trip.

Исправление Zubok, :

Image ­— это структура X-клиента, а pixmap — это объект на стороне сервера X. В случае MIT-SHM, казалось бы, сервер X имеет доступ к клиентской картинке напрямую. Но есть два основных «но»:

1) В случае удаленного клиента у тебя неизбежно должен применяться обычный GetImage/PutImage, что приведет к перегонке картинки по сети туда-обратно. Это надо иметь в виду и использовать Images там, где они действительно эффективны. Например, если ты делаешь много битовых операций над изображением, то тогда правильнее делать это все в Image, а на сервер присылать обновления, чтобы отобразить. Нельзя рассматривать MIT-SHM как средство для использования Image как Pixmap. Его надо рассматривать только как технологию оптимизации в случае, если клиент и сервер находятся на одной машине.

2) Даже если Pixmap и разделяемая Image доступны серверу напрямую, есть важное отличие: операции с pixmap потенциально аппаратно ускорены, в с Image — нет. Pixmaps могут мигрировать между памятью CPU и GPU. Этой миграцией занимаются механизмы 2D ускорения, такие как EXA. Если у тебя pixmaps оказались в памяти GPU (то есть в offscreen memory), а они туда действительно набиваются, то операции копирования областей, например, будет выполнять GPU, если драйвер нормальный, конечно.

(II) EXA(0): Driver allocated offscreen pixmaps
(II) EXA(0): Driver registered support for the following operations:
(II)         Solid
(II)         Copy
(II)         Composite (RENDER acceleration)
(II)         UploadToScreen
(II)         DownloadFromScreen

Если ты используешь OpenGL, то там уже есть расширение, которое умеет Pixmaps преобразовывать в текстуры и манипулировать ими (GLX_EXT_texture_from_pixmap). XImage из разделяемой памяти не может мигрировать в память GPU по определению.

Вот, например, простая вводная: https://techbase.kde.org/Development/Tutorials/Graphics/Performance. Просто замени QPixmap на pixmap, а QImage на XImage. Разве только момент медленности преобразования чуть подправить, так как свои XImage ты можешь в удобном для pixmap формате держать. Тогда преобразования не нужно. Но в общем все так: преобразование Image в Drawable (pixmap или window) и назад - это дорогая операция с дичайшим round-trip.

Исходная версия Zubok, :

Image ­— это структура X-клиента, а pixmap — это объект на стороне сервера X. В случае MIT-SHM, казалось бы, сервер X имеет доступ к клиентской картинке напрямую. Но есть два основных «но»:

1) В случае удаленного клиента у тебя неизбежно должен применяться обычный GetImage/PutImage, что приведет к перегонке картинки по сети туда-обратно. Это надо иметь в виду и использовать Images там, где они действительно эффективны. Например, если ты делаешь много битовых операций над изображением, то тогда правильнее делать это все в Image, а на сервер присылать обновления, чтобы отобразить. Нельзя рассматривать MIT-SHM как средство превращения функции Image в Pixmap. Его надо рассматривать только как технологию оптимизации в случае, если клиент и сервер находятся на одной машине.

2) Даже если Pixmap и разделяемая Image доступны серверу напрямую, есть важное отличие: операции с pixmap потенциально аппаратно ускорены, в с Image — нет. Pixmaps могут мигрировать между памятью CPU и GPU. Этой миграцией занимаются механизмы 2D ускорения, такие как EXA. Если у тебя pixmaps оказались в памяти GPU (то есть в offscreen memory), а они туда действительно набиваются, то операции копирования областей, например, будет выполнять GPU, если драйвер нормальный, конечно.

(II) EXA(0): Driver allocated offscreen pixmaps
(II) EXA(0): Driver registered support for the following operations:
(II)         Solid
(II)         Copy
(II)         Composite (RENDER acceleration)
(II)         UploadToScreen
(II)         DownloadFromScreen

Если ты используешь OpenGL, то там уже есть расширение, которое умеет Pixmaps преобразовывать в текстуры и манипулировать ими (GLX_EXT_texture_from_pixmap). XImage из разделяемой памяти не может мигрировать в память GPU по определению.

Вот, например, простая вводная: https://techbase.kde.org/Development/Tutorials/Graphics/Performance. Просто замени QPixmap на pixmap, а QImage на XImage. Разве только момент медленности преобразования чуть подправить, так как свои XImage ты можешь в удобном для pixmap формате держать. Тогда преобразования не нужно. Но в общем все так: преобразование Image в Drawable (pixmap или window) и назад - это дорогая операция с дичайшим round-trip.