Cairo
-
Портировал Cairo. Теперь можно рисовать всякие интересные вещи. Исходники библиотек на svn. Позже добавлю работу с картинками и шрифты.
- Attachments
-
-
cairo.PNG (19.06 KiB)Viewed 12003 times
-
<3 !
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?
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
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...
Обновил библиотеку и добавил libpng и zlib. Новый сборник http://kolibri-pe.googlecode.com/files/ ... 03.2011.7z.
Update.
Добавил несколько функций в newlibc и перезалил сборник.
Update.
Добавил несколько функций в newlibc и перезалил сборник.
Last edited by Serge on Wed Mar 02, 2011 2:05 am, edited 1 time in total.
Здорово!
*хотет заголовочных файлов и какой-нибудь example.c*
*хотет заголовочных файлов и какой-нибудь example.c*
Sorcerer
Все исходники на svn. Смотри [url]svn://kolibrios.org/programs/develop/libraries[/url]. Пример выложу завтра.
Все исходники на svn. Смотри [url]svn://kolibrios.org/programs/develop/libraries[/url]. Пример выложу завтра.
Serge
А сколько будет весить плеер вместе со всеми дополнениями в конечном виде?
А сколько будет весить плеер вместе со всеми дополнениями в конечном виде?
Mario
+1 Mб, может больше. Разработчики ffmpeg тоже не стоят на месте. Конечный результат сильно зависит от опций компиляции и сборки.
+1 Mб, может больше. Разработчики ffmpeg тоже не стоят на месте. Конечный результат сильно зависит от опций компиляции и сборки.
Залил демо с исходником Требует ядро svn1894+
s/w blitter ?
art_zh
Блиттер в ядре. Я специально сделал новую функцию -73.
65-я с багами и меньше возможностей.
Блиттер в ядре. Я специально сделал новую функцию -73.
65-я с багами и меньше возможностей.
"Любой русский программист после пары минут чтения кода обязательно вскочит и произнесет, обращаясь к себе: переписать это все нафиг." (c)
Предполагается, что уродливый код от gcc с неработающим -mpush-args лучше 65-й функции и багов не содержит?
Предполагается, что уродливый код от gcc с неработающим -mpush-args лучше 65-й функции и багов не содержит?
Сделаем мир лучше!
Serge
я третий месяц долблюсь над переделкой 65-й - сейчас графика (video/graph32) работает очень быстро и гладко длярежимов картинок 32bpp, 24bpp,8bpp,1bpp и "0bpp" (одноцветная заливка прямоугольника), остальные режимы можно безболезненно добавить по ходу дела.
Только код получился нереентерабельный (статические переменные [img_*] затираются при переключении задач) - фиксю через стек.
Может, не стоит умножать сущности? Так или иначе, все равно когда-то надо будет сократить гранулярность экранной карты - она реально ломает весь кэш.
я третий месяц долблюсь над переделкой 65-й - сейчас графика (video/graph32) работает очень быстро и гладко для
Только код получился нереентерабельный (статические переменные [img_*] затираются при переключении задач) - фиксю через стек.
Может, не стоит умножать сущности? Так или иначе, все равно когда-то надо будет сократить гранулярность экранной карты - она реально ломает весь кэш.
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 работал быстрее. Эволюция.
Who is online
Users browsing this forum: No registered users and 33 guests