Понеділок, 5 вересня 2011 р.

Як швидко зобразити видимість прозорого кольору у вашому Qt image viewer


Необхідність вигадати цей велосипед виникла коли я вирішив додати блиску для власної утиліти що спрощує процес вирізання окремих текстур з cut images.
Виявляється алгоритм побудови такого зображення є дуже простим.


void ImageWidget::paintEvent( QPaintEvent * event )
{
    QPainter painter(this);

    const QRect area = event->rect();
    const int square = 8;
    int x = (area.left()%square)*square;
    int y = (area.top()%square)*square;
    while (y < area.bottom()) {
        x = 0;
        while (x < area.right()) {
            const QColor fill = ((x+y)/square)%2?Qt::gray:Qt::lightGray;
            painter.fillRect(x, y, square, square, fill);

            x += square;
        }
        y += square;
    }
}

По моєму вийшло досить лаконічно і дуже непогано.

Попередження: в реальних проектах де потрібно дотримуватися мінливих вимог дизайнерів краще використати QPainter::fillRect( ,QBrush(QPixmap));

Пʼятниця, 21 січня 2011 р.

А ще ось таке юзабіліті ...

Суть проблеми: нові телефони нокії з їхніми новими сімбіанами не показують достатньо інформації в журналі викликів. Немає ні номера телефону ні тривалості розмови. На додачу якщо один і то й же номер телефонував або викликався двічі+ буде показано тільки останній запис.
Всі налаштування складаються з вибору розміру журналу - максимум 30 днів !!!!

На різних форумах в тому числі й офіційних є купа повідомлень подібних до мого, але на жодне з них не дала відповідь якась псевдо офіційна особа.

Якийсь розумник - юзабіліті спеціаліст знайшовся щоб вигадати таке, а щоб пояснити людям ...

Можна миритися з відсутністю номера і тривалості але Журнал який ховає якісь записи і не показує _все_ що в нього записують не може називатися журналом.

Раніше коли я думав що це дістає тільки мене було трохи спокійніше, тепер мене це бісить. Може завтра пройде.

Четвер, 19 лютого 2009 р.

Перестановка пріоритетів

Опис проблеми перестановки пріоритетів в багатозадачних системах (програмах).

Проблема

В плануванні, термін перестановка пріоритетів описує ситуацію коли менш пріоритетне завдання блокує спільні ресурси які необхідні більш пріоритетному завданню. Це призводить блокування більш пріоритетних завдань до тих пір, поки завдання з нижчим пріоритетом розблокує ресурси, насправді "інвертуючи" відносні пріоритети цих двох завдань. Якщо ж в цей час спробує виконатись інше середньо пріоритетне завдання, що не залежить від спільного ресурсу, воно отримає перевагу над менш та більш пріоритетними завданнями.

В деяких ситуаціях перестановка пріоритетів може і не викликати видимих проблем. Проте існує багато ситуацій коли перестановка пріоритетів може призвести до серйозних проблем. Якщо пріоритетне завдання залишиться знемагати без ресурсів, це може привести до несправностей або виклику коректуючих дій, так watch dog timer (пильнуючий таймер) може перевантажити всю систему якщо процес не відповідає вчасно. Проблема що виникла у Mars lander "Mars Pathfinder" є класичним прикладом перестановки пріоритетів в системах реального часу.

Перестановка пріоритетів також може зменшити видиму продуктивність системи.

Рішення

Про існування цієї проблеми відомо з 1970-х, але досі не існує повноцінного методу передбачення таких ситуацій. Основними методами боротьби з цією проблемою є:

  • Відключення всіх переривань для захисту критичних секцій
    Коли відключення всіх переривань використовується для недопущення перестановки пріоритетів існує тільки два типи пріоритетів: резервуючий та блокуючий переривання. Без третього пріоритету перестановка неможлива. Оскільки є тільки один шматок заблокованих даних, хаотичне впорядкування неможливе, тому неможливим стає взаємне блокування (deadlock). Оскільки критичні процеси завжди добігають до завершення зависання не трапляється. Слід пам'ятати що це спрацює тільки якщо всі перериваня відключенні. Коли відключенні тільки деякі апаратні переривання, перестановка пріоритетів відтвориться через пріоритизацію апаратних переривань.
  • Максимізація пріоритетів. (A priority ceiling)
    Із збільшенням пріоритетів до верхньої межі спільний блокуючий процес (що виконує системний код) сам має специфічний (високий) пріоритет, який також присвоєний завданню що тримає блок. Це працює добре не дозволяючи іншим високо пріоритетним завданням мати пріоритет вищий максимального.
  • Успадкування пріоритетів
    За правилами успадкування пріоритетів, якщо високо-пріоритетне завдання має чекати на певний ресурс розділений з менш пріоритетним завданням, мало пріоритетному завданню присвоюється найбільший пріоритет з очікуючих завдань на час використання ним спільних ресурсів, таким чином дозволяючи завданням з середніми та високими пріоритетами уникати затримок (первісно) мало пріоритетного завдання.
Цікаво знати: