Кросплатформенная отрисовка из DLL

[AbakAngelSoft]

Существует приложение с набором расширений в виде dll для платформы Win32.
В экспортируемые функции отвечающие за отрисовку передается HDC (контекст устройства).
Это позволяет не зависеть от языка программирования и среды разработки расширений.
Что передавать в эти функции что бы не зависеть от операционной системы?

[Vadim]

HDC (контекст устройства)

Вот эта штука зависима от Win32. Строится исключительно на WinAPI.
Мало того, DLL - работает только в Windows и больше нигде. Так что этот вариант кроссплатформенности ни капельки не способствует.

[FedeX]

Ну DLL под Linux легко перекомпилируеться в SO так что это по-моему не проблема..
А вместо dc ИМХО лучше бы передавать дескриптор окна, на котором происходит отрисовка. В Win это HWND, а в Lin пожалуй будет хендл Х-окна.. Насчёт последнего не уверен.. А в длл-е (so) в зависимости от платформы получать контекст рисования (надо бы глянуть в реализацию в LCL методов типа WidgetSet.GetDC(hWnd))..

[Vadim]

FedeX
Если речь идёт о рисовании только на формах Lazarus'а, то самым кроссплатформенным методом будет TForm.Canvas.ПроцедурыРисования. И не нужны для этого ни DLL, ни SO, ни вобще чего бы то ни было. Но возможно товарищ хочет рисовать на вообще всём чём угодно, например на Рабочем столе. В этом случае, как ни крути, а получается, как минимум, двойной набор функций - для Win32 и для Х-системы:

Код: Выделить всё

Var
  DC: {$IFDEF WINDOWS}HDC{$ELSE}TGC{$ENDIF};
...
Begin
  DC:={$IFDEF WINDOWS}GetDC(...){$ELSE}XCopyGC(...){$ENDIF};
  ...
End;

Ужос...

[Sergei I. Gorelkin]

Единственный более-менее прямой способ - это передавать в ф-ции dll те объекты, которые создаются/уничтожаются другими ф-циями из той же dll.
Что у этих объектов внутри - знает только dll, приложения это не касается.

[FedeX]

Существует приложение с набором расширений в виде dll для платформы Win32.
Это позволяет не зависеть от языка программирования и среды разработки расширений.

Тоесть, я так понимаю, ни о каких ЛЦЛ-овских Canvas речь не идёт раз нужна независимость от языка и расширяемость за счёт плагинов...
А чтоб плагин мог рисовать что-то на поверхности, ему по-любому нужен платформо зависимый хендл этой поверхности...

FedeX
В этом случае, как ни крути, а получается, как минимум, двойной набор функций - для Win32 и для Х-системы:

Код: Выделить всё

Var
  DC: {$IFDEF WINDOWS}HDC{$ELSE}TGC{$ENDIF};
...
Begin
  DC:={$IFDEF WINDOWS}GetDC(...){$ELSE}XCopyGC(...){$ENDIF};
  ...
End;

Ужос...

Ужос-не ужос, но так часто и приходиться делать

Или ещё можно чтоб плагин рисовал в память, а возвращал только указатель на буфер с уже отрисованным изображением. Это решило-бы большинство проблем, но в плане производительности может быть неприемлемым..

А ещё можно передать в длл указатели на все необходимые функции рисования, експортируемые основным приложением, но рэто по-моему не гибко..

[Vadim]

FedeX
Пока вопрошающий товарищ не поведал нам свои тайный помыслы, можно обсуждать до бесконечности.
А вообще-то для кроссплатформенности самая хорошая штука - OpenGL. И пускай с помощью него не рисуют прямо на рабочем столе сатирические карикатуры на начальника, но с помощью него раздвоения кода будет не так уж много.

[AbakAngelSoft]

Никаких тайных помыслов. Уточню вопрос:

Описанный вариант работает и вполне удовлетворяет требованиям, но исключительно на платформе Win32.
Приложение написано на Delphi, в реестре прописываются плагины (не все плагины делаем мы и не только на Delphi). Когда плагин должен что-то отрисовать приложение вызывает нужную функцию и передает ей ту самую ручку контекста устройства. Как рисовать используя HDC все знают, каждый в своем языке. Во всяком случае вопросов со стороны разработчиков плагинов не возникало - отлично рисуют и сишники и паскалисты.

В связи с финансовым кризисом хочется сделать продукт доступным и для других платформ. Сидим думаем над архитектурой. Насчет рисования адекватного кросплатформенного варианта пока не нашли. Вот решил спросить может кто уже сталкивался и какие решения существуют.

А вместо dc ИМХО лучше бы передавать дескриптор окна, на котором происходит отрисовка.

Чем HWnd лучше dc? С dc возьни меньше ИМХО.

На рабочем столе я рисовать не хочу, но если передавать Canvas - что с ним будут делать делфисты и сишники?

Если рисовать в память - как организовать этот кусок памяти что-бы всем понятно было? просто двумерный массив цветов?

Указатели на все функции рисования - интересно, но громоздко и как Вы правильно сказали не гибко.

Мне и нужен платформонезависымый аналог HDC либо иной вариант решить этот вопрос.

Спасибо за активное обсуждение. У кого есть еще варианты предлагайте! Обещаю когда проблема будет решена оформлю ее решение в виде статьи.

[Vadim]

На рабочем столе я рисовать не хочу, но если передавать Canvas - что с ним будут делать делфисты и сишники?

Легче лёгкого.
Вот код на Дельфи:
Procedure WriteOnCanvas(Canvas: TCanvas; Width, Height: Word);
Begin
//Рисуем эллипс
Canvas.Brush.Color := clRed;
Canvas.Brush.Style := bsDiagCross;
Canvas.Ellipse(0, 0, Width, Height);
End;
На Си рисовать не будем, т.к. Си начисто лишён возможности работать с объектами, а Canvas - это объект. Сишники могут сидеть и уныло пинать балду.
Код на Си++:
void __fastcall WriteOnCanvas(TCanvas *Canvas, Word Width, Word Height)
{
//Типа тоже эллипс
Canvas->Brush->Color = clRed;
Canvas->Brush->Style = bsDiagCross;
Canvas->Ellipse(0, 0, Width, Height);
}

Добавлено спустя 8 минут 36 секунд:
У меня вот только есть смутные подозрения, что в Си++ для Linux нет библиотеки компонентов, аналогичных Борландовскому VCL. Можно, конечно, использовать Kylix, но и на счёт него у меня смутные подозрения, что на современных ОС он будет работать.

[FedeX]

Да, Vadim, так просто использовать в С++ (да и в Делфи) канву из Lazarus не получиться..
Но вообще подобный подход (передавать плагину указатель на обьект главной программы) можно осуществить. Где-то на этом форуме уже несколько раз поднимался этот вопрос. Экземпляр класса в Лазарусе и в Делфи, это по-сути указатель на запись, которая содержит в себе все свойства обьекта (как поля) и поле VMT, которое являеться указателем на массив с указателями на методы класса. Этот формат частично совместим с обьектами из C++. Так, если правильно описать в заголовках для других языков структуру класса TCanvas из Lazarus и передавать в плагин указатель на него, то плагину будут доступны как все методы класса TCanvas, так и Canvas.Handle и пр. полезные вещи. И тогда из плагина можно будет использовать как возможности самого Canvas так и выполнять платформозависимую отрисовку через Canvas.Handle если этих возможностей не хватит.. Единственное что - не уверен, что в других языках есть calling conversion аля ObjectPascal..

[AbakAngelSoft]

Передавать объекты в dll - жуткое решение. Даже в рамках одной среды разработки это не рекомендуется!
Кто пробовал передавать объекты между приложением и библиотекой в рамках Delphi (т.е. когда и приложение и dll написаны на Delphi) знает сколько при этом возникает проблем.
А уж то что объекты FPC, Delphi и C++ несовместимы друг с другом на уровне двоичного представления это наверняка!
Передача VMT это по сути передача интерфейсов (например COM или COBRA) аналогично передаче списка указателей на функции рисования - этот подход уже предлагался.

[Sergei I. Gorelkin]

Если говорить о кроссплатформенности между X и MSWindows... В иксах нет прямого аналога HDC, там в каждую процедуру рисования нужно передавать как Drawable, так и gc. Т.е. аналог виндового HDC будет представлять собой нечто содержащее Drawable + pen_gc + brush_gc + font + region.
Кроме того, для рисования чего-нибудь сложнее точки или линии в иксах обычно используется уже не базовый протокол (с gc), а расширения, в основном RENDER.

Это самое... Возьмите для рисования cairo, там все уже изобретено. Вдобавок не напрягаясь получите печать и вывод в .pdf.

[FedeX]

Передавать объекты в dll - жуткое решение.

Ничего жуткого, если передавать как запись а также создавать и уничтожать обьект только на стороне длл или только на стороне основного приложения. Проблем не будет - гарантированно! Единственно что - жутко не удобно

[AbakAngelSoft]

Повторю еще раз:
Категорически не хочется ограничивать разработчиков плагинов в выборе языка программирования, среды разработки и используемых библиотек. Если разработчик умеет рисовать на своем языке, зачем заставлять его переучиваться?

[Vadim]

Если разработчик умеет рисовать на своем языке, зачем заставлять его переучиваться?

Уроме языка есть ещё и операционная система. К примеру, хотя упёртые сишники и кричат, что ихний язык кроссплатформенный, но с переходом с Цindows на Linux тут же выясняется, что это далеко не так, потому что все приёмы рисования, которые они выучили в Windows, в Linux абсолютно не годятся. Поэтому вопрос "зачем заставлять его переучиваться?" выглядит по меньшей мере странным. Переучиваться нужно не заставлять, переучивание должно быть осознанной необходимостью любого программиста, если он программист конечно, а не упёртый лодырь, считающй себя программистом только потому, что он когда-то что-то выучил с большим трудом и теперь считает, что знает всё на свете и учиться больше не надо. Помнишь "Алису в стране чудес"? - "Надо бежать очень быстро, чтобы только оставаться на одном месте".

Если разработчик умеет рисовать на своем языке...

Мы уже выяснили, что разработчик рисовать на своём языке как раз и не умеет. Дело ещё хуже, чем ты думаешь. С одной стороны разработчик ограничен знанием только одного языка, а с другой стороны ограничен знанием только одной операционной системы.
Но всё очень просто можно поправить. Вы со своими разработчиками берёте книжку по рисованию в иксах и хором её читаете. Совершено неважно на каком языке реализовано рисование. Для настоящего программиста это не принципиально. В своё время не было ни единой книги по применению DirectX или OpenGL в Delphi. Так люди брали книжки по этим темам на Си и успешно учились. Кто бы что ни говорил, но эти языки черезвычайно похожи.
Примените и Вы этот приём. Возмите, к примеру, вот эту книжку:
Программирование в X Window средствами Free Pascal
и узнайте, что нужно для рисования в иксах в общем.\Найдите, в конце концов, учебник по OpenGL:
OpenGL / FPC
При его применении вам вообще не придётся переделывать код рисования для Windows и Linux, кроме некоторых малостей.
К чему я это веду? Вы упёрлись на сегодняшний день в конкретный язык - неважно какой - Си, Дельфи или тому подобное. Отсюда и проблемы. Взгляните лучше на сам принцип рисования, без привязки к языку. Я тебе уже предложил OpenGL как кроссплатформенную рисовалку, но ты это проигнорировал. А зря. С его использованием количество кроссплатформенного кода сократится, как минимум, на 45%, по сравнению с использованием низкоуровневых функций, которые привязаны к конкретной платформе и которые вы использовали раньше. Это тупиковый вариант. Приковывая себя к батарее WinAPI далеко не уйдёшь.