Сообщение Re[62]: Еще от 27.06.2017 19:44
Изменено 27.06.2017 20:08 alex_public
Re[62]: Еще
Здравствуйте, c-smile, Вы писали:
CS>>>Проблема в том что в OpenGL нет понятия context (нечто типа SkPaint или QPainter).
_>>Вообще то как раз есть. Похоже ты не в курсе про существование WGL/GLX/CGL и их кроссплатформенного аналога EGL. ))) Правда тогда непонятно как ты тогда вообще пользуешься OpenGL без знания этого.
CS>Все функции OpenGL работают только с current context, т.е. надо делать такое всегда:
CS>
CS>Т.е. ты не можешь создать два разных context на одном и том же окне. Т.е. Doom и Qt выводить на одно окно не могут — будут друг другу все регистры портить.
Всё верно. Если тебе понадобится в приложение два отдельных OpenGL контекста (кстати, ты уже признаёшь существование такого понятия — прогресс!), то тебе понадобится для этого два отдельных окна (кстати, ты надеюсь в курсе, что они при этом могут быть даже невидимыми?). Только в чём по твоему проблема с созданием двух окон? )
_>>Хотя судя по предыдущему обсуждению для тебя документация и т.п. не являются доказательствами... Тогда перейдём к другой тактики дискуссии, от которой тебе уже будет трудно отмазываться. ))) Тебе кинуть ссылку на работающий пример с кучей opengl виджетов в одном окне? ) Могу даже скомпилировать его и выложить exe. )))
CS>Разные Qt widgets — да. Разные pipelines (Doom и Qt) — нет.
Угу, угу. Интересно только как тогда работает большая часть кода с кастомной прорисовкой на OpenGL совместно с Qt...
_>>И? Что тебе не нравится то? Или опять же требуется показать работающий пример? ) С этим никаких проблем нет... )))
CS>opacity per primitive != layer opacity.
CS>Вот тебе пример: https://jsfiddle.net/xyc514ya/ — первый box это то что ты изобразил. Второй box — то что требуется widget.opacity = 0.7
А где это у нас был разговор про layer opacity? С чего ты взял, что при реализации прозрачности у контрола надо делать не истинную прозрачность (где все его элементы начинают просвечивать), а какой-то убогий и неестественный (в реальности то такого быть не может, если конечно специально не извратиться с поляризацией света) вариант с избирательной (только относительно фона) прозрачностью?
CS>Будешь пытаться воспроизвести? Или разойдемся на этом этапе?
Вообще то в Qt такая убогая штука делается даже ещё проще:
И да, там естественно используется рисование в память. Но при этом мы уже обсуждали, что никто не мешает рисовать в память с помощью GPU.
_>>>>Насколько я помню, у Cairo имеется огромное число бэкендов, включая и OpenGL. Какой из них используется в Gnome я не в курсе. )))
CS>>>Не фантазируй: X Window System (via both Xlib and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output
CS>>>Т.е. по одному backend на платформу + PDF и SVG. Т.е. каждая cairo dll/dylib/so содержит ровно один backend. А PDF и SVG это просто сериализаторы вызовов функций.
_>>Что-то у тебя похоже плохо со зрением. ) Открываем прямо на этом сайте раздел бэкендов https://cairographics.org/backends/ и видим вполне себе здоровенный список, включая вариант с OpenGL. )))
CS>Я именно это и написал. Для каждой платформы там свой backend. Т.е. cairo.dll включает в себя только windows specific код. От общего размера — меньше 10%.
CS>OpenGL experimental и не используется в production нигде. Собирать нужно отдельно. Я это делал. Ты — нет.
Так получается OpenGL бэкенд у Cairo не существует (как утверждал ты) или же нигде не используется (я кстати и не утверждал, что он где-то используется, хотя опять же возможно и это твоё утверждение не верно — надо проверять)? )))
_>>Ты хочешь сказать, что ты действительно не в курсе, что можно рисовать в память через GPU? )))
CS>Ты вообще дискуссию читал ли? Мы же рисование в GPU и обсуждаем ...
Правильно. И я тебе говорю, что из того факта, что некая система оперирует окнами как готовыми картинками (текстурами) совершенно не следует, что эти картинки не были перед этим так же отрисованы с помощью GPU (рисование могло происходить в память, а не на экран).
CS>>>Проблема в том что в OpenGL нет понятия context (нечто типа SkPaint или QPainter).
_>>Вообще то как раз есть. Похоже ты не в курсе про существование WGL/GLX/CGL и их кроссплатформенного аналога EGL. ))) Правда тогда непонятно как ты тогда вообще пользуешься OpenGL без знания этого.
CS>Все функции OpenGL работают только с current context, т.е. надо делать такое всегда:
CS>
CS>wglMakeCurrent(...);
CS>CS>Т.е. ты не можешь создать два разных context на одном и том же окне. Т.е. Doom и Qt выводить на одно окно не могут — будут друг другу все регистры портить.
Всё верно. Если тебе понадобится в приложение два отдельных OpenGL контекста (кстати, ты уже признаёшь существование такого понятия — прогресс!), то тебе понадобится для этого два отдельных окна (кстати, ты надеюсь в курсе, что они при этом могут быть даже невидимыми?). Только в чём по твоему проблема с созданием двух окон? )
_>>Хотя судя по предыдущему обсуждению для тебя документация и т.п. не являются доказательствами... Тогда перейдём к другой тактики дискуссии, от которой тебе уже будет трудно отмазываться. ))) Тебе кинуть ссылку на работающий пример с кучей opengl виджетов в одном окне? ) Могу даже скомпилировать его и выложить exe. )))
CS>Разные Qt widgets — да. Разные pipelines (Doom и Qt) — нет.
Угу, угу. Интересно только как тогда работает большая часть кода с кастомной прорисовкой на OpenGL совместно с Qt...
_>>И? Что тебе не нравится то? Или опять же требуется показать работающий пример? ) С этим никаких проблем нет... )))
CS>opacity per primitive != layer opacity.
CS>Вот тебе пример: https://jsfiddle.net/xyc514ya/ — первый box это то что ты изобразил. Второй box — то что требуется widget.opacity = 0.7
А где это у нас был разговор про layer opacity? С чего ты взял, что при реализации прозрачности у контрола надо делать не истинную прозрачность (где все его элементы начинают просвечивать), а какой-то убогий и неестественный (в реальности то такого быть не может, если конечно специально не извратиться с поляризацией света) вариант с избирательной (только относительно фона) прозрачностью?
CS>Будешь пытаться воспроизвести? Или разойдемся на этом этапе?
Вообще то в Qt такая убогая штука делается даже ещё проще:
QGraphicsOpacityEffect effect(&my_widget);
my_widget.setGraphicsEffect(&effect);
effect->setOpacity(0.5);И да, там естественно используется рисование в память. Но при этом мы уже обсуждали, что никто не мешает рисовать в память с помощью GPU.
_>>>>Насколько я помню, у Cairo имеется огромное число бэкендов, включая и OpenGL. Какой из них используется в Gnome я не в курсе. )))
CS>>>Не фантазируй: X Window System (via both Xlib and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output
CS>>>Т.е. по одному backend на платформу + PDF и SVG. Т.е. каждая cairo dll/dylib/so содержит ровно один backend. А PDF и SVG это просто сериализаторы вызовов функций.
_>>Что-то у тебя похоже плохо со зрением. ) Открываем прямо на этом сайте раздел бэкендов https://cairographics.org/backends/ и видим вполне себе здоровенный список, включая вариант с OpenGL. )))
CS>Я именно это и написал. Для каждой платформы там свой backend. Т.е. cairo.dll включает в себя только windows specific код. От общего размера — меньше 10%.
CS>OpenGL experimental и не используется в production нигде. Собирать нужно отдельно. Я это делал. Ты — нет.
Так получается OpenGL бэкенд у Cairo не существует (как утверждал ты) или же нигде не используется (я кстати и не утверждал, что он где-то используется, хотя опять же возможно и это твоё утверждение не верно — надо проверять)? )))
_>>Ты хочешь сказать, что ты действительно не в курсе, что можно рисовать в память через GPU? )))
CS>Ты вообще дискуссию читал ли? Мы же рисование в GPU и обсуждаем ...
Правильно. И я тебе говорю, что из того факта, что некая система оперирует окнами как готовыми картинками (текстурами) совершенно не следует, что эти картинки не были перед этим так же отрисованы с помощью GPU (рисование могло происходить в память, а не на экран).
Re[62]: Еще
Здравствуйте, c-smile, Вы писали:
CS>>>Проблема в том что в OpenGL нет понятия context (нечто типа SkPaint или QPainter).
_>>Вообще то как раз есть. Похоже ты не в курсе про существование WGL/GLX/CGL и их кроссплатформенного аналога EGL. ))) Правда тогда непонятно как ты тогда вообще пользуешься OpenGL без знания этого.
CS>Все функции OpenGL работают только с current context, т.е. надо делать такое всегда:
CS>
CS>Т.е. ты не можешь создать два разных context на одном и том же окне. Т.е. Doom и Qt выводить на одно окно не могут — будут друг другу все регистры портить.
Всё верно. Если тебе понадобится в приложение два отдельных OpenGL контекста (кстати, ты уже признаёшь существование такого понятия — прогресс!), то тебе понадобится для этого два отдельных окна (кстати, ты надеюсь в курсе, что они при этом могут быть даже невидимыми?). Только в чём по твоему проблема с созданием двух окон? )
_>>Хотя судя по предыдущему обсуждению для тебя документация и т.п. не являются доказательствами... Тогда перейдём к другой тактики дискуссии, от которой тебе уже будет трудно отмазываться. ))) Тебе кинуть ссылку на работающий пример с кучей opengl виджетов в одном окне? ) Могу даже скомпилировать его и выложить exe. )))
CS>Разные Qt widgets — да. Разные pipelines (Doom и Qt) — нет.
Угу, угу. Интересно только как тогда работает большая часть кода с кастомной прорисовкой на OpenGL совместно с Qt...
_>>И? Что тебе не нравится то? Или опять же требуется показать работающий пример? ) С этим никаких проблем нет... )))
CS>opacity per primitive != layer opacity.
CS>Вот тебе пример: https://jsfiddle.net/xyc514ya/ — первый box это то что ты изобразил. Второй box — то что требуется widget.opacity = 0.7
А где это у нас был разговор про layer opacity? С чего ты взял, что при реализации прозрачности у контрола надо делать не истинную прозрачность (где все его элементы начинают просвечивать), а какой-то убогий и неестественный (в реальности то такого быть не может, если конечно специально не извратиться с поляризацией света) вариант с избирательной (только относительно фона) прозрачностью?
CS>Будешь пытаться воспроизвести? Или разойдемся на этом этапе?
Вообще то в Qt такая убогая штука делается даже ещё проще:
И да, там естественно используется рисование в память. Но при этом мы уже обсуждали, что никто не мешает рисовать в память с помощью GPU.
_>>>>Насколько я помню, у Cairo имеется огромное число бэкендов, включая и OpenGL. Какой из них используется в Gnome я не в курсе. )))
CS>>>Не фантазируй: X Window System (via both Xlib and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output
CS>>>Т.е. по одному backend на платформу + PDF и SVG. Т.е. каждая cairo dll/dylib/so содержит ровно один backend. А PDF и SVG это просто сериализаторы вызовов функций.
_>>Что-то у тебя похоже плохо со зрением. ) Открываем прямо на этом сайте раздел бэкендов https://cairographics.org/backends/ и видим вполне себе здоровенный список, включая вариант с OpenGL. )))
CS>Я именно это и написал. Для каждой платформы там свой backend. Т.е. cairo.dll включает в себя только windows specific код. От общего размера — меньше 10%.
CS>OpenGL experimental и не используется в production нигде. Собирать нужно отдельно. Я это делал. Ты — нет.
Так получается OpenGL бэкенд у Cairo не существует (как утверждал ты) или же нигде не используется (я кстати и не утверждал, что он где-то используется, хотя опять же возможно и это твоё утверждение не верно — надо проверять)? )))
_>>Ты хочешь сказать, что ты действительно не в курсе, что можно рисовать в память через GPU? )))
CS>Ты вообще дискуссию читал ли? Мы же рисование в GPU и обсуждаем ...
Правильно. И я тебе говорю, что из того факта, что некая система оперирует окнами как готовыми картинками (текстурами) совершенно не следует, что эти картинки не были перед этим так же отрисованы с помощью GPU (рисование могло происходить в память, а не на экран).
CS>>>Проблема в том что в OpenGL нет понятия context (нечто типа SkPaint или QPainter).
_>>Вообще то как раз есть. Похоже ты не в курсе про существование WGL/GLX/CGL и их кроссплатформенного аналога EGL. ))) Правда тогда непонятно как ты тогда вообще пользуешься OpenGL без знания этого.
CS>Все функции OpenGL работают только с current context, т.е. надо делать такое всегда:
CS>
CS>wglMakeCurrent(...);
CS>CS>Т.е. ты не можешь создать два разных context на одном и том же окне. Т.е. Doom и Qt выводить на одно окно не могут — будут друг другу все регистры портить.
Всё верно. Если тебе понадобится в приложение два отдельных OpenGL контекста (кстати, ты уже признаёшь существование такого понятия — прогресс!), то тебе понадобится для этого два отдельных окна (кстати, ты надеюсь в курсе, что они при этом могут быть даже невидимыми?). Только в чём по твоему проблема с созданием двух окон? )
_>>Хотя судя по предыдущему обсуждению для тебя документация и т.п. не являются доказательствами... Тогда перейдём к другой тактики дискуссии, от которой тебе уже будет трудно отмазываться. ))) Тебе кинуть ссылку на работающий пример с кучей opengl виджетов в одном окне? ) Могу даже скомпилировать его и выложить exe. )))
CS>Разные Qt widgets — да. Разные pipelines (Doom и Qt) — нет.
Угу, угу. Интересно только как тогда работает большая часть кода с кастомной прорисовкой на OpenGL совместно с Qt...
_>>И? Что тебе не нравится то? Или опять же требуется показать работающий пример? ) С этим никаких проблем нет... )))
CS>opacity per primitive != layer opacity.
CS>Вот тебе пример: https://jsfiddle.net/xyc514ya/ — первый box это то что ты изобразил. Второй box — то что требуется widget.opacity = 0.7
А где это у нас был разговор про layer opacity? С чего ты взял, что при реализации прозрачности у контрола надо делать не истинную прозрачность (где все его элементы начинают просвечивать), а какой-то убогий и неестественный (в реальности то такого быть не может, если конечно специально не извратиться с поляризацией света) вариант с избирательной (только относительно фона) прозрачностью?
CS>Будешь пытаться воспроизвести? Или разойдемся на этом этапе?
Вообще то в Qt такая убогая штука делается даже ещё проще:
QGraphicsOpacityEffect effect(&my_widget);
my_widget.setGraphicsEffect(&effect);
effect.setOpacity(0.5);И да, там естественно используется рисование в память. Но при этом мы уже обсуждали, что никто не мешает рисовать в память с помощью GPU.
_>>>>Насколько я помню, у Cairo имеется огромное число бэкендов, включая и OpenGL. Какой из них используется в Gnome я не в курсе. )))
CS>>>Не фантазируй: X Window System (via both Xlib and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output
CS>>>Т.е. по одному backend на платформу + PDF и SVG. Т.е. каждая cairo dll/dylib/so содержит ровно один backend. А PDF и SVG это просто сериализаторы вызовов функций.
_>>Что-то у тебя похоже плохо со зрением. ) Открываем прямо на этом сайте раздел бэкендов https://cairographics.org/backends/ и видим вполне себе здоровенный список, включая вариант с OpenGL. )))
CS>Я именно это и написал. Для каждой платформы там свой backend. Т.е. cairo.dll включает в себя только windows specific код. От общего размера — меньше 10%.
CS>OpenGL experimental и не используется в production нигде. Собирать нужно отдельно. Я это делал. Ты — нет.
Так получается OpenGL бэкенд у Cairo не существует (как утверждал ты) или же нигде не используется (я кстати и не утверждал, что он где-то используется, хотя опять же возможно и это твоё утверждение не верно — надо проверять)? )))
_>>Ты хочешь сказать, что ты действительно не в курсе, что можно рисовать в память через GPU? )))
CS>Ты вообще дискуссию читал ли? Мы же рисование в GPU и обсуждаем ...
Правильно. И я тебе говорю, что из того факта, что некая система оперирует окнами как готовыми картинками (текстурами) совершенно не следует, что эти картинки не были перед этим так же отрисованы с помощью GPU (рисование могло происходить в память, а не на экран).