Eto: Поддержка OpenGL Render Control.

Специально не планировалось, но сделать достаточно легко. Похоже, OpenTK имеет лицензию MIT, поэтому он хорошо сочетается с Eto.Forms.

Однако могут возникнуть некоторые сложности, так как вам придется скомпилировать свое приложение с разными ссылками на основе целевой платформы, если только у Eto.Forms не будет своего рода обертка вокруг OpenTK, что я не обязательно хотел бы делать.

Я заметил, что у вас есть отдельные библиотеки DLL платформы для Windows, Gtk и Mac, разве это не место для размещения кода, специфичного для платформы.
чтобы использовать OpenTK, вам нужно будет сослаться на одну общую независимую платформу OpenTK.dll и одну конкретную платформу, код которой может быть добавлен в существующую Eto.Platform. *. dll, поскольку они, скорее всего, уже содержат необходимые ссылки.

Я работал над изменением и удалением вилки OpenTK, найденной на https://github.com/hultqvist/opentk.
Но имейте в виду, что у fork есть некоторые серьезные изменения, которые делают его несовместимым с исходным проектом Opentk (в основном с использованием векторов-столбцов).

Тем не менее та часть, о которой я говорю, не изменилась в этом отношении, в частности проекты OpenTK.GLControl и OpenTK.GLWidget для Windows и Gtk соответственно, я думаю, что аналогичный может быть создан для Mac, но в настоящее время единственная реализация от оригинала Класс OpenTK gamewindow.

В самом деле, это был бы способ сделать это.

Я немного посмотрел на это - жаль, что MonoMac использует собственный OpenTK, встроенный в MonoMac.dll .. Возможно, нам придется создать оболочку для всего API, что было бы неудачно

Прогресс был достигнут в элементе управления OpenGL для eto здесь:

https://github.com/bchavez/SharpFlame/tree/eto/source

Находится ли этот элемент управления OpenGL в рабочем состоянии?

Я не пробовал его, поэтому я не уверен, хотя я видел скриншоты его работы в SharpFlame .. @bchavez , у вас есть дополнительная информация о состоянии вашего элемента управления OpenGL?

• Eto.Gl - _Eto Control_, но я еще не формализовал API.
• Eto.Gl.Windows - GL для конкретной платформы должен работать в Windows как есть, используя Eto.Gl .
• Eto.Gl.Linux - Специфичный для платформы GL в Linux нуждается в обновлении в связи с некоторыми новыми изменениями eto . Обновить должно быть несложно, просто не хватило времени.
• Eto.Gl.Mac - Достаточно сложная проблема, которую я хочу решить.

Одна из основных проблем Mac / OSX заключается в том, что по умолчанию новые контексты GL, созданные в одном приложении, не используются совместно с ресурсами. Это означает, что вы получаете изолированный контекст ресурса GL для каждой поверхности. IE: Если у вас есть приложение, которое использует несколько поверхностей GL, вам нужно будет загружать текстуры n раз на поверхность, занимая n умноженное на объем памяти текстур.

Это поведение отличается в Linux и Windows, по умолчанию новые контексты OpenGL являются общими ресурсами (в одном приложении). Итак, если у вас есть несколько поверхностей GL (в Linux или Windows) в одном приложении и вы загружаете текстуры, вы загружаете ресурсы текстуры только один раз, а не n раз на поверхность.

Некоторые из попыток взлома, которые я предпринял, чтобы заставить его работать на Mac, - MacGLView1-7.cs :
https://github.com/bchavez/SharpFlame/tree/eto/source/Eto.Gl.Mac

В конце концов, я (или кто-то другой) решу проблему, чтобы поведение было согласованным на разных платформах. Просто не хватило времени на банкомат.

Документ OSX по проблеме находится здесь:

https://developer.apple.com/library/mac/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_contexts/opengl_contexts.html

Чтобы уточнить, под «контекстом GL» я подразумеваю, в частности, контексты ресурсов GL . (Состояние общего объекта, как описано по ссылке выше).

Спасибо за разъяснение. Я уже пытался заставить его работать в Windows и Linux.
Windows отлично работает с Wpf, но в Linux с Gtk # 2 работать не хочет: http://hastebin.com/okewirerem
Вот код, если вы хотите взглянуть на него: https://github.com/PowerOfCode/Eto/tree/opengl-control/Source/Eto.Gl.Gtk

Я выяснил, что это как-то связано с отрисовкой текста. Если у вас есть какой-либо другой элемент управления в макете, который отображает текст, он мгновенно аварийно завершает работу. Если вместо этого текст этого элемента управления пуст, сбой не произойдет.

Вау, это странно.

@benklett

Я столкнулся с той же проблемой. Если вы все еще не нашли исправление, вы должны поместить это как первую строку вашей программы gtk:

C# [STAThread] public static void Main(string[] args) { //this MUST be the first line in the program or any text + the opengl window will cause it to segfault OpenTK.Toolkit.Init (); ....

Это из-за какой-то дурацкой вещи с x_multithreading или чем-то в этом роде, поэтому OpenTK должен попасть туда до инициализации gtk. Не совсем первое, что вам нужно сделать, но довольно рано.

Большое вам спасибо за вашу помощь, мне нужно будет попробовать, сработает ли это, когда я вернусь домой.

Есть какие-нибудь обновления в элементе управления OpenGL для eto?

Выглядит многообещающе: https://github.com/philstopford/etoViewport.

Re. etoViewport, он мог бы работать с поддержкой WPF и GTK3, но GTK3 озадачивает меня, как действовать дальше - не очевидно, как настроить необходимый (для меня) контекст Cairo.

Дуно, как etoViewport это делает, но в Gtk 3 есть виджет GLArea для рендеринга OpenGL: https://developer.gnome.org/gtk3/unstable/GtkGLArea.html

Есть обновления по этому поводу?

@feliwir etoViewport на

GTK работает в моих тестах под VirtualBox / CentOS 7.x, а также под VMWare / Linux Mint. Может быть некоторая странность драйвера, особенно в VirtualBox, где элемент управления OpenGL, кажется, плавает над всеми другими окнами. Я думаю, что это может быть ошибка в VirtualBox, поскольку она не видна в VMWare.

Однако GTK3 не реализован для etoViewport.

@philstopford Мне не нравится зависимость от OpenTK, какие-либо планы по ее удалению / разрешению настраиваемого обратного вызова для создания контекста?

Мне жаль, что тебе это не нравится, но я не понимаю почему. Патчи приветствуются, если текущий подход вам не подходит. Сам я не собираюсь менять его: OpenTK был надежной рабочей лошадкой. Раньше я использовал SharpGL, а затем этот проект был заброшен. Напротив, OpenTK активно поддерживается и является многоплатформенным.

Перемещено по адресу :

@cwensley это можно закрыть.