Не перерисовывается фон, когда неактивное окно изменяет своё положение

Kernel-side graphics support
  • Serge wrote:
    По идее, при пустой очереди его должны принудительно в спячку переводить, нет?
    Наверное мы термин "принудительно" по-разному понимаем. Сам, потому что это процесс вызывает блокирующие ф.10 или ф.23. Инициатор перехода в режим ожидания сам процесс. Проверил события, если ничего нет поставил флаг ожидания TASKDATA.state=5 и ушёл спать через change_task. Если будет проверять события ф.11, будет работать без остановок. Принудительно вытесняет только планировщик.
    По-разному. (Ну и еще я ядро ваше мало изучал пока что, ориентируюсь на общепринятое поведение)
    Не сам: он сам просит отдать последнее собщение, когда оно будет, он себя усыпить не просит - если мессАж есть на месте, он получит управление тут же. А вот уж ядро думает: нет для тебя касатик, ни фига, сиди спи, не трать процессорное время мне тут :lol: Или у вас не так?
  • Не думает ядро ничего, у него для этого мозгов нет. Делает только то, что программист написал.
    он себя усыпить не просит
    Еще как просит. Программист. "Если нет сообщений, то спать. Разбудите, когда будут новости". Если не надо спать, применяется ф.11
    Для меня "принудительно" означает, что вытеснение происходит независимо от желания программиста. А когда это ожидаемое поведение функции, ну какая здесь принудительность ?
  • Serge wrote:Не думает ядро ничего, у него для этого мозгов нет. Делает только то, что программист написал.
    Это позерство и игра словами. Слово "думает" применено в значении "есть логика для действия Х, которую заложил программист". Уверен, ты понял, о чем я.
    он себя усыпить не просит
    Еще как просит. Программист. "Если нет сообщений, то спать. Разбудите, когда будут новости". Если не надо спать, применяется ф.11
    Неа. Если сообщения есть, то нужен возврат. Программа не заинтересована в том, чтобы спать, ей это вообще не нужно. В идеале она бы вообще весь процессор под себя подмяла. А вот ядро ее усыпляет, когда той точно делать нечего. Это ядро вызывает условный putToSleepMode(ThreadID), а не программа. Они ж программы, несознательные. Как дети малые. А было б иначе - не нужна была бы нам вытесняющая многозадачность.

    Я о внутренней реализации. Потому что блокирующий вызов необзательно через сон реализуется, и может быть реализован просто в лоб: spinиться в течение своего кванта времени, опрашивая очередь сообщений, пока смена контекста не произойдет. Это тоже блокирующий вызов для той же самой Ф10. Просто тупая реализация. А в норме в отсутствие сообщений "по ту сторону", в ядре, поток будет кинут ядром в сон. И там и там - блокирующая Ф10, программа просила одно и то же. А вот в реализации 1 сна нет, в реализации 2 - есть. Так что тут что программа запросила - значения не имеет по отношению ко сну. Она просила не возвращаться, а не спать. Сон - деталь реализации.

    Ты лучше вот что скажи: ты упомянул в какой-то теме, что Intel рекомендует использовать MUL вместо IMUL, так как MUL-де быстрее. Не назовешь, что за документ ты имеешь в виду? А то я проглядел ряд документов по оптимизации - везде MUL и IMUL отнесены к одной категории по спариванию и по тактам.
  • Программа не заинтересована в том, чтобы спать, ей это вообще не нужно. В идеале она бы вообще весь процессор под себя подмяла.
    Не надо одушевлять программы и наделять их свободой воли. Программист решает, что лучше для программы и в целом для системы. Реально программе всегда нужно спать, иначе она посадит аккумулятор и перегреет процессор.
    Она просила не возвращаться, а не спать. Сон - деталь реализации.
    Ключевая деталь. Программа (программист конечно) просила не тратить процессорное время. Иначе ф.10 просто не нужна, есть ф.11
    Ф.10 и 23 это классика кооперативной многозадачности. Их применение как раз говорит о том, что желательна передача управления другому процессу, а не пустая трата циклов в ожидании вытеснения планировщиком. В старых Win, например, принудительного вытеснения не было совсем.
  • Serge wrote:Не надо одушевлять программы и наделять их свободой воли. Программист решает, что лучше для программы и в целом для системы. Реально программе всегда нужно спать, иначе она посадит аккумулятор и перегреет процессор.
    Я разберусь, что надо :wink: Это просто фигура речи, не придирайся. Программе не нужно спать. Ей пофигу на аккумулятор, она выполняет поставленную задачу. Задача ОС - разделять ресурсы, втч процессорное время.
    Ключевая деталь. Программа (программист конечно) просила не тратить процессорное время.
    Не-а. Она просила не возвращаться.
    Представь, что Ф10 реализована тупо (в псевдокоде):

    Code: Select all

    while (!PeekMessage(Message)) do;
    return Message;
    Вызов блокирующий? Да. А сна - нет. Потому что ядерная часть вызова не усыпила поток.

    Тут - иначе:

    Code: Select all

    Count = 100;
    GotMessage = False;
    while (!(GotMessage = PeekMessage(Message))) && (Count > 0) do Count--;
    if(!GotMessage)
      SleepWaitingFor(MessageQueue);
    GotMessage = PeekMessage(Message);
    if(GotMessage)
      return Message
     else
       return -1;
    А и там и там - вызов блокирующий.
    Иначе ф.10 просто не нужна, есть ф.11
    Притянуто за уши. Так-то можно считать, что никакие библиотеки не нужны, потому что все можно руками сделать.
    Их применение как раз говорит о том, что желательна передача управления другому процессу, а не пустая трата циклов в ожидании вытеснения планировщиком
    Не-а. API предполагает, что вызов блокирующий. И это все. Представь, что есть альтернативная Колибри, которая реализует тот же самый API, но Ф10 - как в варианте 1. Для программы - никакой разницы, она так же отработает. Усыпляет ее ядро.
    В старых Win, например, принудительного вытеснения не было совсем.
    А стырые - это какие? NT 89 года, в которой уже есть WaitForSingleObject - старая?
  • //DG
    Тут надо понимать суть происходящего.
    Ядро - это всего лишь код. Код, который исполняется процессом, также как и любая функция; считай, библиотека. Когда программа вызывает сисфункцию, происходит смена прав и стека, и программа продолжает работать в ядре. Если программа падает в ядре, завершается её процесс; вся система при этом не падает - её это никак не касается.

    Так вот, внутри ф. 10 программа проверяет наличие событий, если их нет - засыпает в ожидании, при этом происходит смена процесса. Применительно к данному багу, программа может в одном потоке заниматься какой-то периодической фоновой деятельностью, а не только рисованием окна.
  • Это просто фигура речи, не придирайся.
    Эта фигура речи выводит за скобки программиста и переворачивает всё с ног на голову.
    Программе не нужно спать.
    У программы вообще нет потребностей, они есть у программиста.
    Не-а. Она просила не возвращаться.
    Не-а. API предполагает, что вызов блокирующий. И это все.
    Может обратиться к официальной документации ?

    Code: Select all

    ======================================================================
    ==================== Функция 10 - ожидать события. ===================
    ======================================================================
    Если очередь сообщений пуста, то ждет появления сообщения в очереди.
    В таком состоянии поток не получает процессорного времени.
    Затем считывает сообщение из очереди.
    ======================================================================
    ==================== Function 10 - wait for event. ===================
    ======================================================================
    If the message queue is empty, waits for appearance of the message
    in queue. In this state thread does not consume CPU time.
    Then reads out the message from queue.
    
    Здесь не предположение, здесь прямо написано
    не получает процессорного времени
    does not consume CPU time
    А стырые - это какие?
    Windows 1.0 - 3.х Старые операционки от Apple тоже были с кооперативной многозадачностью. И оставались такими, пока Джобс не вернулся.
  • Pathoswithin wrote://DG
    Тут надо понимать суть происходящего.
    Ядро - это всего лишь код. Код, который исполняется процессом, также как и любая функция; считай, библиотека. Когда программа вызывает сисфункцию, происходит смена прав и стека, и программа продолжает работать в ядре. Если программа падает в ядре, завершается её процесс; вся система при этом не падает - её это никак не касается.

    Так вот, внутри ф. 10 программа проверяет наличие событий, если их нет - засыпает в ожидании, при этом происходит смена процесса. Применительно к данному багу, программа может в одном потоке заниматься какой-то периодической фоновой деятельностью, а не только рисованием окна.
    Я, разумеется, понимаю это. Это вопрос терминологии - "ядро делает" = код ядра делает, пусть даже в потоке исполнения самой программы. Ясно, что ядро - не отдельный поток.
  • Serge wrote:
    Это просто фигура речи, не придирайся.
    Эта фигура речи выводит за скобки программиста и переворачивает всё с ног на голову.
    Да никоим образом. И так понятно, что программа - не субъект. Когда мы говорим "программа делает", или "программе нужно", понятно, что речь идет о логике, заложенной программистом. Придираться здесь так же нелепо, как и ко фразе "поезд сбил человека", мол не поезд, а машинист, это же он управлял.
    У программы вообще нет потребностей, они есть у программиста.
    Игра слов, не более. См. выше. Программе, выполняющей задачу, обслуживающей потребности программиста, не нужно спать, ей нужно выполнять задачу, разделяя время с другими программами. "Спать" - это не задача программы, это вынужденное состояние простоя, побочка в чистом виде.
    Еще было бы неплохо понимать, что программа и ядро могут быть написаны разными людьми, у которых разные устремления, выраженные через их ПО.
    Здесь не предположение, здесь прямо написано
    не получает процессорного времени
    Отлично. Смотри сам: программа не получает. Не получает, потому что является зависимым объектом, не она решает, сколько квантов времени она будет занимать процессор.
    Ты что писал?
    Но это процесс сам в такое состояние переходит.
    Как процесс может сам перейти в такое состояние, если его принудительно усыпили и лишили процессорного времени внутри системного вызова, т.е. в ядре, кодом, созданным другим программистом для других целей? Если процесс вызывает функцию вида Sleep(10), он иницирует сон, в Ф10 же сон побочное действие. В Ф10 для процесса нет разницы - усыпили его или нет, для него это все равно миг: нырнул в сискол - вернулся.

    Твой аргумент сводится к тому, что процесс усыпляет себя сам, потому что он сам просит себя усыпить, если надо. Я же говорю, что если он просит, то он не выполняет действия самостоятельно, его выполняет код ядра (написанный другим программистом в общем случае). Да, в том же потоке выполнения, но это деталь реализации. Здесь просто терминологическая разница: ты и pathoswithin считаете, что "тело" сискола - это процесс, потому что выполняется потоком исполнения процесса, я же считаю это ядром, потому что это отдельный участок кода, написанный другим разработчиком для других целей, который может что-либо сделать принудительно на нулевом кольце, в отличие от кода третьего кольца, которое и выполнялось потоком исполнения до входа в сискол.

    Мы действительно по-разному понимаем термин "принудительно", забей. Это мелочь.
    Ты лучше про MUL и IMUL поясни.
  • Да, в том же потоке выполнения, но это деталь реализации.
    Как раз не деталь. Передача управления другому потоку её ключевая особенность. Кстати та самая PeekMessage из WinAPI тоже передаёт управление, если программист не поставит PM_NOYIELD. Наследство кооперативной многозадачности.
    Мы действительно по-разному понимаем термин "принудительно", забей. Это мелочь.
    Вот поэтому учёные и говорят: "Сначала надо определиться с терминологией"
    Ты лучше про MUL и IMUL поясни.
    Не нашёл уже. Наверное эта рекомендация была для очень старых процессоров.
  • Кстати, так, к слову. Сейчас у меня закончится один серьезный проект на работе, будет больше времени. Я буду делать RTL для FPC с ООП обвязкой для box_lib. Есть ли что-нибудь, над чем нужно потрудиться в ядре? Относительно отдельный участок.
    Как раз не деталь. Передача управления другому потоку её ключевая особенность.
    Ты не понял - передача кванта другому потоку - не деталь, это ключевая особенность, верно. Я сказал, что деталь - реализуется ли это текущим потоком исполнения, или иным. Потому что с т.з. прикладной программы не будет разницы, если данное действие выполнит другой поток - для нее вызов будет по-прежнему блокирующим с возможным засыпанием.
  • Если сдвигаем окно на 1 пиксель вбок, то окно под ним не отрисовывает этот 1 пиксель.
    Attachments
    wnd.png
    wnd.png (35.37 KiB)
    Viewed 8757 times
    Из хаоса в космос
  • Leency,
    Seems to be fixed in #9221. Related to this report.
  • dunkaist wrote:Leency,
    Seems to be fixed in #9221. Related to this report.
    G-d bless you!
    Из хаоса в космос
  • Who is online

    Users browsing this forum: No registered users and 1 guest