Здравствуйте, adontz, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>Давай. Я сегодня закончу это безобразие в первом приближении.
A>Заодно опиши для русской аудитории этимологию названия.
Кстати.
Для нужд лого требуется фото графинцика. Можно с огурчиком и газетой "Правда".
Есть у кого?
Здравствуйте, c-smile, Вы писали: CS>Кстати. CS>Для нужд лого требуется фото графинцика. Можно с огурчиком и газетой "Правда". CS>Есть у кого?
Выбери здесь. Если что понравится, купим.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
В качестве опции, возможно было бы полезно взять интерфейс OpenVG. Конечно, оно вам не очень-то надо, но в качестве потенциального пиара возможно было бы неплохо. Правда комитет вряд ли даст статус официальной OpenVG имплементации, поскольку они ничего кроме FSAA не признают. Ну и к тому же, OpenVG страдает некоторыми серьезными недостатками, как то stateful модель, предполагающую наличие статических данных. Но вообще-то, некоторые идеи можно было бы перенять, например модель Path — чтобы была возможность одним вызовом рисовать произвольные фигуры. В OpenVG это практически прямое мапирование путей из SVG и XAML.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, c-smile, Вы писали:
CS>>Кстати. CS>>Для нужд лого требуется фото графинцика. Можно с огурчиком и газетой "Правда". CS>>Есть у кого?
MS>А еще "Гармонь" — был вроде бы у тебя такой проект. Графин, стакан, огурец и гармонь. Это нормально...
На самом деле, да, еще вот на выходе проект stakan.dll — инкапсуляция GUI message pump и абстракция окна верхнего уровня.
Таки да, сей предмет для гармони полmзителен. Ну и для sciter опять же.
В принципе коцепция выборки сообщений идентична для win и xlib (да и в дарвин)- задрала если честно
необходимость каждый раз лисапеты делать.
Здравствуйте, Anpek, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
A>А как скачать-то можно? A>Ссылка svn checkout http://graphin.googlecode.com/svn/trunk/ graphin что-то не работает в Тортилле
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, c-smile, Вы писали:
CS>>graphin dll это внешне простой графический движок который содержит CS>>agg, png, jpeg. Движок имплементирует внешний интерфейс (plain C) с объектами CS>>http://terrainformatica.com/sciter/Graphics.whtm и http://terrainformatica.com/sciter/Image.whtm.
CS>>Нечто типа GDI+ только быстрее и "мультиплатформеннее" что ли.
MS>В качестве опции, возможно было бы полезно взять интерфейс OpenVG. Конечно, оно вам не очень-то надо, но в качестве потенциального пиара возможно было бы неплохо. Правда комитет вряд ли даст статус официальной OpenVG имплементации, поскольку они ничего кроме FSAA не признают. Ну и к тому же, OpenVG страдает некоторыми серьезными недостатками, как то stateful модель, предполагающую наличие статических данных. Но вообще-то, некоторые идеи можно было бы перенять, например модель Path — чтобы была возможность одним вызовом рисовать произвольные фигуры. В OpenVG это практически прямое мапирование путей из SVG и XAML.
Path это имхо половина дела. На самом деле полезнее было бы иметь возможнось сериализации последовательности вообще всех операций (а не только line_to cо товарищи) с возможностью параметризации таких последоавтельностей. Нечто типа metafiles или "двоичного svg". Павел (коржик который) в принципе сделал прямую интерпретацию
svg (для htmlayout/sciter) — т.е. в принципе можно и svg (в текстовом виде — как есть) использовать.
В принципе простейший интерфейс который я использую позволяет сериализовать последовательности в некий гпрафический байткод без всяких проблем.
Ключевой момент — парметрические блоки и параметризация. Как пример практической реалии: rounded rect с заливкой который растягивается на весь контейнер сохраняя радиус закруглений вне зависимости от размера контейнера.
Вот это вот реально имеет смысл — тогда можно было бы действительно собирать изображение из строительных блоков некоей библиотеки.
Здравствуйте, Anpek, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>Странно, а так например ты файл видишь: CS>>http://graphin.googlecode.com/svn/trunk/include/graphin.h
A>Вижу. A>Может я не так Торитллой ползуюсь — просто она пишет что нет такого URL-а
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, c-smile, Вы писали: CS>>Кстати. CS>>Для нужд лого требуется фото графинцика. Можно с огурчиком и газетой "Правда". CS>>Есть у кого? S>Выбери здесь. Если что понравится, купим.
А чего-то не лежит душа к тому стеклу...
Я вот нашел картинку Петрова-Водкина "Подсвечник и Графин". Душевно.
Кузьма Сергеич мастер был однако...
Здравствуйте, Caduceus, Вы писали:
C>Что-то, судя по смайлику, подвох какой-то
Почти любая Open Source лицензия подразумевает определенные ограничения и условия использования. Поэтому если слова "New BSD License" ни о чем не говорят, то надо просто взять и прочитать текст лицензии. Только не надо спрашивать, где взять.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[4]: А можно использовать в коммерческом приложении
Здравствуйте, c-smile, Вы писали:
CS>Тогда и лицензия на graphin поменяется. Пока нет планов переходить на 2.5.
На 2.5 переходить не обязательно. Можно, но смысла особого нет. Надо будет переходить на 2.6, которой пока еще нет в природе — ну, если захочется, конечно. И я думаю, что мы вполне можем выработать такое решение, при котором Графин останется под BSD или другой, более либеральной лицензией, чем GPL.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[8]: А можно использовать в коммерческом приложении
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, c-smile, Вы писали:
CS>>Тогда и лицензия на graphin поменяется. Пока нет планов переходить на 2.5.
MS>На 2.5 переходить не обязательно. Можно, но смысла особого нет. Надо будет переходить на 2.6, которой пока еще нет в природе — ну, если захочется, конечно. И я думаю, что мы вполне можем выработать такое решение, при котором Графин останется под BSD или другой, более либеральной лицензией, чем GPL.
Было бы замечательно.
План по поводу Графина следующий: сделать essential graphics_layer — нечто типа рабочего subset/super set GDI который уже можно безболезненно расширять плюс сделать платформо-независимый набор window_*** и application_*** функций.
В принципе то что что сейчас есть в http://graphin.googlecode.com/svn/trunk/include/window.h для нужд htmlayout/sciter меня устраивает. Я думаю это также устроит весь класс приложений которым нужны "просто окна" от платформы (например fltk со товарищи). В том числе и твои тестовые примеры. Я так думаю. Как бы еще это так организвать ко взаимной удобности и взаимозаменяемости ...
// stdafx.h : include file for standard system include files,
// or project specific include files that are used frequently, but
// are changed infrequently
//
Здравствуйте, runtime2, Вы писали:
R>Здравствуйте, c-smile, Вы писали:
R>Немного сбивает с толка objects.h
R>// stdafx.h : include file for standard system include files, R>// or project specific include files that are used frequently, but R>// are changed infrequently R>//
R>
Здравствуйте, ShaggyOwl, Вы писали: SO>Ой, я тоже думал, что шучу SO>А если действительно заинтересовала, у автора в профиле вроде были указаны координаты ...
Я тут в субботу был в неплохом кабаке, где случайно снял близкий сюжет на Canon IXUS 700. Когда донесу его до работы — выложу. Если общая идея подойдет, то могу зафотать более точный натюрморт, с газетом (если их еще печатают) и прочим.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Я тут в субботу был в неплохом кабаке, где случайно снял близкий сюжет на Canon IXUS 700. Когда донесу его до работы — выложу. Если общая идея подойдет, то могу зафотать более точный натюрморт, с газетом (если их еще печатают) и прочим.
Там на ссылке использована световая кисть — фототехника, принципиально возможная только с фотопленкой.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Оччень хочется иметь портированный под Symbian 9-й версии вариант! Вроде бы тамошнее Open C позволит это сделать без слишком больших проблем. Ну уж очень вкусное решение получилось бы — возможность писАть одинаковый интерфейс для двух главных мобильных платформ — WinCE и Symbian.
Здравствуйте, Left2, Вы писали:
L>Вроде бы тамошнее Open C позволит это сделать без слишком больших проблем. Ну уж очень вкусное решение получилось бы — возможность писАть одинаковый интерфейс для двух главных мобильных платформ — WinCE и Symbian.
Именно что "вроде бы". Нет у меня ни девайсов ни development environment под Symbian.
Попробуй скомплировать сам.
Здравствуйте, Left2, Вы писали:
L>Оччень хочется иметь портированный под Symbian 9-й версии вариант! Вроде бы тамошнее Open C позволит это сделать без слишком больших проблем. Ну уж очень вкусное решение получилось бы — возможность писАть одинаковый интерфейс для двух главных мобильных платформ — WinCE и Symbian.
Опасаюсь, что Antigrain, как чисто софтварный рендерер будет весьма тормозить на слабых процессорах. Хотя, есть прецеденты использования. Ну, это примерно как на древнем P-II 266MGz.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
MS>Опасаюсь, что Antigrain, как чисто софтварный рендерер будет весьма тормозить на слабых процессорах. Хотя, есть прецеденты использования. Ну, это примерно как на древнем P-II 266MGz.
Ну, процы на современных Symbian-девайсах стоят ненамного более слабые чем на Windows Mobile. Да и разрешение экрана всё же порядком поменьше чем на десктопах
Здравствуйте, c-smile, Вы писали:
CS>Открыл на google code проект Graphin.
CS>graphin dll это внешне простой графический движок который содержит CS>agg, png, jpeg. Движок имплементирует внешний интерфейс (plain C) с объектами CS>http://terrainformatica.com/sciter/Graphics.whtm и http://terrainformatica.com/sciter/Image.whtm.
CS>Нечто типа GDI+ только быстрее и "мультиплатформеннее" что ли.
Небольшое наблюдение
у тебя для чтения jpeg под windows используется файл отображаемый в память и jpeg_mem_src(). Я попробовал читать jpeg большого размера таким способом и это оказалось медленнее использования jpeg_stdio_src(). Возможно это только у меня, или чтение файлов небольшого размера осуществляется быстрее твоим способом.
Здравствуйте, runtime2, Вы писали:
R>Небольшое наблюдение R>у тебя для чтения jpeg под windows используется файл отображаемый в память и jpeg_mem_src(). Я попробовал читать jpeg большого размера таким способом и это оказалось медленнее использования jpeg_stdio_src(). Возможно это только у меня, или чтение файлов небольшого размера осуществляется быстрее твоим способом.
