Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну да, уже посоветовали. Были б эти функции в общем списке GDI functions — давно б сам нашел.
Нашёл ниже только ScrollDC. ScrollWindow тебе ещё и правильно окно инвалидирует так, что тебе надо будет перерисовать только новую область без изображения, которая возникла после сдвига.
Здравствуйте, Евгений Музыченко, Вы писали:
_>>Его надо перерисовывать.
ЕМ>Когда надо — перерисовываю. Но это медленно.
У вас чтото странное. В 9м году я делал так плавный быстрый скроллинг дотнете и все было быстро, гладко.
_>>Если риует долго разбейте на тайлы и кэшируйте их.
ЕМ>Не понял, чем это будет отличаться от сдвига, кроме того, что станет значительно сложнее.
Где именно вы видите сложность? У вас ровно один тайл.
Здравствуйте, Pauel, Вы писали:
P>В 9м году я делал так плавный быстрый скроллинг дотнете и все было быстро, гладко.
И параллельно у Вас работал звуковой поток с буферизацией в единицы миллисекунд? Если всю мгновенную производительность процессора отдать на перерисовку, у меня тоже все "быстро, гладко", только поток трещит.
P>Где именно вы видите сложность?
В добавлении совершенно лишних сущностей и кода/данных для их обслуживания.
Здравствуйте, Евгений Музыченко, Вы писали:
P>>В 9м году я делал так плавный быстрый скроллинг дотнете и все было быстро, гладко.
ЕМ>И параллельно у Вас работал звуковой поток с буферизацией в единицы миллисекунд? Если всю мгновенную производительность процессора отдать на перерисовку, у меня тоже все "быстро, гладко", только поток трещит.
Смешной аргумент. Думаете 14 лет назад процы быстрее были, да на тормозном на тот момент дотнете?
Это конкретно ваше решение пожирает процессор. В норме такого быть не должно.
P>>Где именно вы видите сложность?
ЕМ>В добавлении совершенно лишних сущностей и кода/данных для их обслуживания.
Эти "совершенно лишние" сущности уменьшают потребление процессора до нуля.
Здравствуйте, Pauel, Вы писали:
P>Эти "совершенно лишние" сущности уменьшают потребление процессора до нуля.
Вы пробовали читать то, что я пишу, или ориентируетесь исключительно на отдельные слова?
Еще раз, медленно, с расстановкой:
— При отрисовке графика по ходу работы потока (по одной точке каждой величины за цикл) потребление процессора меньше 1%, отрисовка не мешает работе звукового потока.
— При сдвиге графика с помощью BitBlt или ScrollWindow, и последующей отрисовке одного комплекта точек потребление процессора меньше 1%, отрисовка не мешает работе звукового потока.
— При поточечной перерисовке всего графика при каждом сдвиге в окне из нескольких сотен точек по каждому измерению (это около сотни раз в секунду) потребление процессора возрастает до 25-30% и начинает мешать работе звукового потока.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>- При поточечной перерисовке всего графика при каждом сдвиге в окне из нескольких сотен точек по каждому измерению (это около сотни раз в секунду) потребление процессора возрастает до 25-30% и начинает мешать работе звукового потока.
Потому что ты неправильно делаешь поточечную перерисовку. Если выводить по точкам в промежуточный буфер (нет, не через SetPixel, а через buffer.memory[x + y * buffer.stride] = color, а потом на экран за один BitBlt, то это будет ничуть не медленнее и технически намного проще.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Если выводить по точкам в промежуточный буфер (нет, не через SetPixel
Я использую не SetPixel, а MoveToEx/LineTo, поскольку масштаб может меняться, и точки графика могут не соответствовать точкам экрана.
TB>а через buffer.memory[x + y * buffer.stride] = color, а потом на экран за один BitBlt, то это будет ничуть не медленнее
Если б я это делал для релиза, и нужно было обеспечить быструю перерисовку при перекрытии окон, то рисовал бы линиями в Memory DC, чтоб не делать линии вручную, а перерисовку фрагмента делал бы через BitBlt.
TB>и технически намного проще.
Только в ситуации, когда точка графика соответствует точке экрана.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если б я это делал для релиза, и нужно было обеспечить быструю перерисовку при перекрытии окон, то рисовал бы линиями в Memory DC, чтоб не делать линии вручную, а перерисовку фрагмента делал бы через BitBlt.
Ну да, как-то так, разве это не проще?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>- При поточечной перерисовке всего графика при каждом сдвиге в окне из нескольких сотен точек по каждому измерению (это около сотни раз в секунду) потребление процессора возрастает до 25-30% и начинает мешать работе звукового потока.
ЕМ>Как еще нужно объяснить, чтоб стало понятно?
Читайте себя выше. Не совсем ясно, зачем вы сотни раз в секунду чего то выводите. У вас цель процессор съесть?
Для плавности хватит 50 раз в секунду или даже чуть меньше. Все остальное — лишнее.
Поточечно нужно выводить только новую часть. Остальное шлепается из буфера.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если б я это делал для релиза, и нужно было обеспечить быструю перерисовку при перекрытии окон, то рисовал бы линиями в Memory DC, чтоб не делать линии вручную, а перерисовку фрагмента делал бы через BitBlt.
Тогда непонятен ваш начальный вопрос. Выглялит, так будто вы знаете оптимальный вариант, и просите подсказать субоптимальный
TB>>и технически намного проще.
ЕМ>Только в ситуации, когда точка графика соответствует точке экрана.
Это лечится трансформацией координат и перерисовкой при изменении масштаба
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>О, спасибо! Очередное подтверждение тому, что виндовая документация убога — функций ScrollDC, ScrollWindow, ScrollWindowEx нет в общем списке функций GDI, только в разделе Scroll Bars, хотя напрямую оно никак не связано.
Здравствуйте, Евгений Музыченко, Вы писали:
_>>Добавление промежуточного кэширующего слоя не должно влиять на сложность отрисовки ЕМ>Даже если этот класс где-то существует в готовом виде, уже заточенный под мои потребности, мне придется, как минимум, ознакомиться с его интерфейсом, привязаться к нему, вставить его в текстовом виде или обеспечить линковку. Если же его не существует, мне придется его спроектировать, написать, отладить, а затем сделать с ним все, перечисленное выше. Если, по-Вашему, это не меняет уровень сложности моего кода, то как Вы определяете для себя понятие "сложность"?
o_O ? если вам лень возьмите готовые библиотеки отрисовки графиков.
_>>Если у вас рисует медленно значит точек много ЕМ>Еще раз, для тех, кому лень вчитаться в уже написанный текст: рисует быстро, перерисовывает медленно, если для сдвига влево использовать полную перерисовку, которая даже идеологически для этой цели некорректна.
Что значит перерисовывает. С тайлами можно рисовать в фоне и в разных потоках. И не перерисовывать то что не изменялось. А в WM_PAINT уже рисовать быстро, уже подготовленные участки или если еще не готовы можно рисовать заглушки.
Здравствуйте, Pavel Dvorkin, Вы писали:
ЕМ>>функций ScrollDC, ScrollWindow, ScrollWindowEx нет в общем списке функций GDI
PD>Потому что это не wingdi, а winuser
Речь не о "функциях, реализованных в gdi32.dll" (по этому признаку вообще нет смысла что-либо группировать), а о "функциях, относящихся к отрисовке", "функциях, работающих с графикой/изображениями" и т.п.
Почему, например, SetPixel включена в список "bitmap functions", а ScrollDC — нет? Обе работают с контекстами и манипулируют пикселами. По уму, должен быть полный список функций по принадлежности, например, к работе с контекстами. В том же MFC ScrollDC включена в класс HDC, что вполне логично.
, чтобы наблюдать за параметрами потока реального времени. Графики выводятся в темпе изменения состояния потока. Поэтому код может быть сколь угодно корявым и примитивным — главное, чтоб он был быстрым.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Почему, например, SetPixel включена в список "bitmap functions", а ScrollDC — нет? Обе работают с контекстами и манипулируют пикселами. По уму, должен быть полный список функций по принадлежности, например, к работе с контекстами. В том же MFC ScrollDC включена в класс HDC, что вполне логично.
Об этом надо спросить тех, кто делал user и gdi в Windows 1.0 . А потом изменить было уже невозможно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>потом изменить было уже невозможно.
В какой момент стало невозможно добавить в документацию отдельные списки, вроде "device context functions", "functions working with graphics data" и т.п.? Да хоть включить ScrollDC в Bitmap Functions, ей там самое место.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В какой момент стало невозможно добавить в документацию отдельные списки, вроде "device context functions", "functions working with graphics data" и т.п.? Да хоть включить ScrollDC в Bitmap Functions, ей там самое место.
Так в отдельный список и добавлено. Но не в тот список
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так в отдельный список и добавлено. Но не в тот список
А как найти-то? Я ж подчеркивал, что по словам "move" или "shift" найти нереально. Более того, во многих дискуссиях, которые находятся по этим словам, обсуждается та же задача, что и у меня, но отсылок к ScrollDC/ScrollWindow там нет. По-моему, это показатель качества и связности документации.
