Cairo
Posted: Tue Mar 01, 2011 10:20 am
Портировал Cairo. Теперь можно рисовать всякие интересные вещи. Исходники библиотек на svn. Позже добавлю работу с картинками и шрифты.
Page 1 of 3
Re: Cairo
Posted: Tue Mar 01, 2011 1:17 pm
<3 !
Re: Cairo
Posted: Tue Mar 01, 2011 11:07 pm
Nice work Serge.
It makes me wonder, is there a specific reason you are porting all those C libraries?
It makes me wonder, is there a specific reason you are porting all those C libraries?
Re: Cairo
Posted: Wed Mar 02, 2011 12:15 am
hidnplayr
I will try to use cairo in Fplay. And Firefox using cairo for rendering all content. Who knows...
I will try to use cairo in Fplay. And Firefox using cairo for rendering all content. Who knows...
Re: Cairo
Posted: Wed Mar 02, 2011 12:50 am
Обновил библиотеку и добавил libpng и zlib. Новый сборник http://kolibri-pe.googlecode.com/files/ ... 03.2011.7z.
Update.
Добавил несколько функций в newlibc и перезалил сборник.
Update.
Добавил несколько функций в newlibc и перезалил сборник.
Re: Cairo
Posted: Wed Mar 02, 2011 1:00 am
Здорово!
*хотет заголовочных файлов и какой-нибудь example.c*
*хотет заголовочных файлов и какой-нибудь example.c*
Re: Cairo
Posted: Wed Mar 02, 2011 2:08 am
Sorcerer
Все исходники на svn. Смотри [url]svn://kolibrios.org/programs/develop/libraries[/url]. Пример выложу завтра.
Все исходники на svn. Смотри [url]svn://kolibrios.org/programs/develop/libraries[/url]. Пример выложу завтра.
Re: Cairo
Posted: Wed Mar 02, 2011 9:25 am
Serge
А сколько будет весить плеер вместе со всеми дополнениями в конечном виде?
А сколько будет весить плеер вместе со всеми дополнениями в конечном виде?
Re: Cairo
Posted: Wed Mar 02, 2011 7:52 pm
Mario
+1 Mб, может больше. Разработчики ffmpeg тоже не стоят на месте. Конечный результат сильно зависит от опций компиляции и сборки.
+1 Mб, может больше. Разработчики ffmpeg тоже не стоят на месте. Конечный результат сильно зависит от опций компиляции и сборки.
Re: Cairo
Posted: Fri Mar 04, 2011 12:45 pm
s/w blitter ?
Re: Cairo
Posted: Fri Mar 04, 2011 2:04 pm
art_zh
Блиттер в ядре. Я специально сделал новую функцию -73.
65-я с багами и меньше возможностей.
Блиттер в ядре. Я специально сделал новую функцию -73.
65-я с багами и меньше возможностей.
Re: Cairo
Posted: Fri Mar 04, 2011 2:26 pm
"Любой русский программист после пары минут чтения кода обязательно вскочит и произнесет, обращаясь к себе: переписать это все нафиг." (c)
Предполагается, что уродливый код от gcc с неработающим -mpush-args лучше 65-й функции и багов не содержит?
Предполагается, что уродливый код от gcc с неработающим -mpush-args лучше 65-й функции и багов не содержит?
Re: Cairo
Posted: Fri Mar 04, 2011 3:11 pm
Serge
я третий месяц долблюсь над переделкой 65-й - сейчас графика (video/graph32) работает очень быстро и гладко длярежимов картинок 32bpp, 24bpp,8bpp,1bpp и "0bpp" (одноцветная заливка прямоугольника), остальные режимы можно безболезненно добавить по ходу дела.
Только код получился нереентерабельный (статические переменные [img_*] затираются при переключении задач) - фиксю через стек.
Может, не стоит умножать сущности? Так или иначе, все равно когда-то надо будет сократить гранулярность экранной карты - она реально ломает весь кэш.
я третий месяц долблюсь над переделкой 65-й - сейчас графика (video/graph32) работает очень быстро и гладко для
Только код получился нереентерабельный (статические переменные [img_*] затираются при переключении задач) - фиксю через стек.
Может, не стоит умножать сущности? Так или иначе, все равно когда-то надо будет сократить гранулярность экранной карты - она реально ломает весь кэш.
Re: Cairo
Posted: Fri Mar 04, 2011 3:59 pm
CleverMouse
Не все процессоры умеют быстро вычислять адреса операндов для последовательныx push push push push push.
65 не работает. Я пытался её использовать, не вышло. И её текущая реализация не соответствует описанию. Например stride (ebp) для 32 и 24 bpp посылается нафиг, что совершенно неприемлемо.
art_zh
Когда новая сияющая ф.65 появится на транке я с радостью буду её использовать, если
1. Она будет учитывать задаваемую ширину строки в байтах, а не вычислять её по-своему разумению.
2. Поддерживать отрицательные координаты точки для левого верхнего угла назначения.
3. Поддерживать отрицательные координаты точки для левого верхнего угла источника.
4. Всегда получать базовый адрес источника, а не модифицированный для вывода части источника со смещением x,y. В этом случае драйвер сможет однозначно опознать текстуру источника и не загонять eё лишний раз в gart или видеопамять. GPU предъявляет жёсткие требования к выравниванию данных - 32\64 байта. Будет ещё больше. Выравнивание на 4 не пойдёт.
ф.65 не позволяет всё это сделать.
P.S.
diamond сделал ф.65 чтобы KFar работал быстрее. Эволюция.
Не все процессоры умеют быстро вычислять адреса операндов для последовательныx push push push push push.
65 не работает. Я пытался её использовать, не вышло. И её текущая реализация не соответствует описанию. Например stride (ebp) для 32 и 24 bpp посылается нафиг, что совершенно неприемлемо.
art_zh
Когда новая сияющая ф.65 появится на транке я с радостью буду её использовать, если
1. Она будет учитывать задаваемую ширину строки в байтах, а не вычислять её по-своему разумению.
2. Поддерживать отрицательные координаты точки для левого верхнего угла назначения.
3. Поддерживать отрицательные координаты точки для левого верхнего угла источника.
4. Всегда получать базовый адрес источника, а не модифицированный для вывода части источника со смещением x,y. В этом случае драйвер сможет однозначно опознать текстуру источника и не загонять eё лишний раз в gart или видеопамять. GPU предъявляет жёсткие требования к выравниванию данных - 32\64 байта. Будет ещё больше. Выравнивание на 4 не пойдёт.
ф.65 не позволяет всё это сделать.
P.S.
diamond сделал ф.65 чтобы KFar работал быстрее. Эволюция.