Board.KolibriOS.org

Posted: **Sun Nov 06, 2016 12:48 pm**

А в чём магия? Что мой код всего лишь на строчку короче? Ну да, компиляторы неплохо оптимизируют код... нормальный код, без ООП.

Posted: **Tue Nov 08, 2016 2:23 am**

Там вон viewtopic.php?f=9&t=2122&p=66983#p66982 перестало работать.
Предположительно из-за этого изменения http://websvn.kolibrios.org/filedetails ... 75#line-28

Posted: **Tue Nov 08, 2016 3:34 am**

Pathoswithin wrote:А в чём магия? Что мой код всего лишь на строчку короче? Ну да, компиляторы неплохо оптимизируют код... нормальный код, без ООП.

Я ошибся - код одинаковый, по 11 команд.
И у компилятора тоже есть неочевидная для меня

Code: Select all

lea   eax, DWORD PTR [eax+eax*2]

Так что счет равный.

Влил ToolTip и пример использования в библиотеку.
В исходниках - полезная для будущих компонент фича для использования структур в асме.

Spoiler:

Code: Select all

Пишем один раз описание структуры
struc tooltip txt, next, zone_x, zone_w, zone_y, zone_h, col_txt, col_bkg, tm_wait
{
    .txt     dd  txt   ; указатель на текст asciiz, разделитель \r 13
    .next    dd  next	; следующиий tooltip в цепочке или 0
    .zone_y  dw  zone_y   ; зона контроля (в 90% случаев совпадает с размером контрола)
    .zone_x  dw  zone_x   ;
    .zone_h  dw  zone_h   ;
    .zone_w  dw  zone_w   ;
    .col_txt dd  col_txt   ; цвет текста тултипа, включая размер SysFn4
    .col_bkg dd  col_bkg   ; цвет фона тултипа
    .tm_wait dw  tm_wait   ; время ожидания х10мс
;временные переменные
    .font_sz dd  ?   ; font size
    .mouse   dd  ?   ; предыдущее положение (x, y)
    .tm_strt dd  ?   ; время запуска таймера (входа мыши в зону) х10мс
    .video   dd  ?   ; память для сохраненного под тултипом
    .video_y dw  ?    ; координаты запомненной области экрана, или 0 если пусто
    .video_x dw  ?
    .video_h dw  ?    ; размер предрасчитывается при init
    .video_w dw  ?
}

virtual at edi
	ttip tooltip ?, ?, ?, ?, ?, ?, ?, ?, ?
end virtual

Потом используем 
    mov edi, [ttip] ;  регистр смещения указанный в virtual
   обращаемся просто 
    mov [ttip.mouse], 0
   ...
    stdcall get_font_size, [ttip.col_txt]
итп

Posted: **Tue Nov 08, 2016 3:44 am**

Siemargl, молодец, конечно, что старался.
Но это всё-таки не совсем tooltip получился.
Tooltip это вот на скриншоте viewtopic.php?f=24&t=1220&start=315#p66855 А у тебя просто квадратик рисуется.
Ну ничего, в принципе, как пример это можно оставить.
Как только появится время, постараюсь добавить нормальный ToolTip.

В исходниках - полезная для будущих компонент фича для использования структур в асме.

кстати, можно нормально пользоваться структурами в асм через virtual директиву. см новый тултип

Америку открыл, да?

Posted: **Tue Nov 08, 2016 4:50 am**

Насчёт editbox-a.
Думаю, лучше было взять дополнительные байты из "внутренних" переменных, таких как, например, ed_shift_pos, ed_shift_pos_old, cl_curs_x, cl_curs_y. Потому как реально там не нужно по 4 байта. Сами эти переменные можно сдвинуть в памяти, они же внутренние, их никто кроме самого editbox-а не использует. Так что, это ещё и экономия памяти.

Posted: **Tue Nov 08, 2016 10:40 am**

0CodErr wrote:Siemargl, молодец, конечно, что старался.
Но это всё-таки не совсем tooltip получился.
Tooltip это вот на скриншоте viewtopic.php?f=24&t=1220&start=315#p66855 А у тебя просто квадратик рисуется.

Дизайнер есть, насоветует - рисовку улучшим.

0CodErr wrote:
В исходниках - полезная для будущих компонент фича для использования структур в асме.
кстати, можно нормально пользоваться структурами в асм через virtual директиву. см новый тултип
Америку открыл, да?

Судя по коду бокс_либ и твоим проблемам с байтами - таки открыл )

Posted: **Tue Nov 08, 2016 10:52 am**

Siemargl, посчитай ещё раз.
Мой код (без "магии"):

Code: Select all

        mov     ecx,ed_text_color
        mov     ebx,ecx
        shr     ecx,28
        shr     ebx,24
        and     ebx,7
        inc     ebx
        mov     eax,6
        jecxz   @f
        mov     al, 8
@@:
        mul     bl

Впрочем, мерятся с компилятором всё равно что играть с ботами...

Posted: **Tue Nov 08, 2016 11:12 am**

Так нечестно - ты сейчас выкинул and c маской и у тебя jecx отработает при любых старших битах, например asciiz.

В целом я и не спорю, что ручная оптимизация лучше, да и компилятор иногда такое нарисует (особо относится к gcc),
а поинт был в том, что если уж писать асм руками, то делать это понятным для человека.

Раз пошла такая пьянка, вот ресурс, позволяющий оценить, что напишет бот-компилятор для примера, с выбором ботов. А потом уже можно и напильником.
AFAIK, компиляторы пока сами не умеют хорошо использовать SSE.

Posted: **Tue Nov 08, 2016 1:59 pm**

and dword ed_text_color,17FFFFFFh - это общая валидация для всего editbox, она нужна в обоих случаях.

А ещё, компиляторы не умеют использовать rep movs, lods, stos...

Posted: **Tue Nov 08, 2016 2:00 pm**

Хорошо, я сам это сделаю тогда viewtopic.php?f=24&t=1220&p=67000#p66992
Никто ведь не против сохранения обратной совместимости?

Pathoswithin, подумай насчёт высоты шрифта, там тоже не надо 4 байта. Может ещё для чего-нибудь сгодится, для флагов там каких-нибудь.

Posted: **Tue Nov 08, 2016 2:16 pm**

Pathoswithin wrote:and dword ed_text_color,17FFFFFFh - это общая валидация для всего editbox, она нужна в обоих случаях.
А ещё, компиляторы не умеют использовать rep movs, lods, stos...

В данном случае нет. Компилятор тестирует конкретный бит.

0CodErr wrote:Хорошо, я сам это сделаю тогда viewtopic.php?f=24&t=1220&p=67000#p66992
Никто ведь не против сохранения обратной совместимости?
Pathoswithin, подумай насчёт высоты шрифта, там тоже не надо 4 байта. Может ещё для чего-нибудь сгодится, для флагов там каких-нибудь.

Я против - ты поломаешь C-Layer, а у gcc какие то болячки с отключением выравнивания в структурах. Еще потом с байтами трахаться (со словами не придется).
Лучше исправить поломавшиеся программы на нормальный код с родными бокс_либовскими макросами

Posted: **Tue Nov 08, 2016 2:23 pm**

Siemargl ух кокой толстый тролинг

Кому не нравится обратная совместимость, могут смело форкать проект.

Posted: **Thu Nov 10, 2016 10:30 am**

Проверил. Экономия 12 байт в структуре стоит дополнительных 32 байта в коде из-за префикса размера у не 32-битных команд в 32-битном режиме.

Posted: **Fri Nov 11, 2016 11:23 am**

Pathoswithin, ты собираешься исправлять или как?

Экономия 12 байт в структуре стоит дополнительных 32 байта в коде

А ты сейчас серьёзно насчёт экономии памяти?
Тогда я тебе тоже сейчас серьёзно и отвечу.
Для трёх EditBox-ов экономия составит уже 12 * 3 = 36 байт, в то время как в коде BoxLib это будут по-прежнему те же самые 32 байта.

Siemargl wrote:Я против - ты поломаешь C-Layer

Отвечу тебе твоими же словами. Тебе нужно всего-то

Siemargl wrote:исправить поломавшиеся программы на нормальный код с родными бокс_либовскими макросами

То есть, следуя твоей логике, сами структуры из BoxLib можно менять хоть каждый день, хоть по нескольку раз в день. Главное макросы использовать. Причём непременно для fasm

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

Я пока обнаружил проблемы в RunOD(сейчас исправлено), GenFiles, fNav, вероятно, что также WebView и Eolite.

Вообще, хотелось бы по этому поводу комментариев администрации. Я считаю, что такое положение дел это ну никак нормальным назвать нельзя. А представьте, что проблемы с совместимостью возникли бы у гораздо большего количества разработчиков, например 20-30?

Если говорить обо мне, то это для меня не проблема, чтобы просто взять и вкомпилировать код EitBox-а "как есть" в само приложение. Это уж точно избавило бы от возможных проблем с совместимостью.

Posted: **Fri Nov 11, 2016 11:40 am**

Еще и скорость обращения к полусловам наверное тоже ниже, хотя для интерфейсной части это вряд ли критично.

>То есть, следуя твоей логике, сами структуры из BoxLib можно менять хоть каждый день, хоть по нескольку раз в день. Главное макросы использовать. Причём непременно для fasm
Именно. Автосборка системы решает эту проблему, а fasm - стандартный для системы транслятор. Новая версия системных библиотек тянет за собой требование к тестированию и/или обновлению юзер-программ, это всегда и везде так.

>Я пока обнаружил проблемы в RunOD(сейчас исправлено), GenFiles, fNav, вероятно, что также WebView и Eolite.
В С-- структура уже исправлена (т.е.WebView и Eolite вычеркиваем), остальные можешь проверить и сказать, поломались или нет )

>Если говорить обо мне, то это для меня не проблема, чтобы просто взять и вкомпилировать код EitBox-а "как есть" в само приложение. Это уж точно избавило бы от возможных проблем с совместимостью.
Такая идеология в static linux http://sta.li

Board.KolibriOS.org

box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов

Re: box_lib.obj - библиотека gui компонентов