Выяснилось, как разъясняет https://bugreports.qt.io/browse/QTBUG-44291, задержка происходит при создании QPinter в src/plugins/printsupport/windows/qwindowsprintdevice.cpp:238:QWindowsPrintDevice::printableMargins() (This is slow, need to cache values or find better way! Modify the DevMode to get the DC printable margins in device pixels) .

Теперь надо показать юзеру, что наша прога не зависла, а лишь слегка задумалась. Идея со скрытым окном не прокатит, за время работы проги, юзер может изменит дефолтный принтер и нам надо по новой его инициализировать. ПрогрессДиалог то же не пойдет, он будет тупо висеть без индикатора.

Qt5.6 Win7 У меня время появления диалога ~ 4-5 сек. Порой кажется что на кнопку печати не нажал и нажимаю еще раз, или же что приложение подвисло. С чем связана такая заторможенность? Как ускорить появление?

Для того, что бы понять некоторые сущности, надо привести аналогию. Например, операционная система (ОС) - это женщина. Вы купили новое оборудование, микроволновку, и теперь надо свою женщину научить с ней работать, типа драйвер, при этом по хрену Windows или Linux, или еще как либо зовут Вашу, так сказать "Бабу", ебите как хотите , но с микроволновкой она работать обязана. Так вот убогость состоит не в "Винде" или "Линухе", а в Ваших, бля, руках. Любите свою бабу, так как любите самого себя, до самой жопы. Но у некоторых есть потребность любить не одну женщину, и зачастую это зависит от заказа. Поэтому мы "Программеры" обязаны как шлюхи удовлетворять всяким потребительским потребностям. Пойдите и спросите у проститутки кто для нее убогий.

Обнаружил самостоятельное появление QProgressDialog без вызова show() в Qt5.6 при переносе проекта из более ранней версии. При чем, при закоменнтированной  "progressDialog.setValue(0)" окно появляется стандартно через 4 секунды не смотря на duration==0, а при разкомментированной - окно появляется сразу.

C++ (Qt)
int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
 
    MainWindow mainWindow;
    mainWindow.show();
 
    QProgressDialog progressDialog(&mainWindow);
    progressDialog.setWindowModality(Qt::WindowModal);
    progressDialog.setMinimumDuration(0);
    progressDialog.setAutoClose(false);
    progressDialog.setAutoReset(false);
    // progressDialog.setValue(0);
 
    // QObject::connect(&mainWindow, SIGNAL(buttonClicked()), &progressDialog, SLOT(show()));
 
    return a.exec();
}
 

Попробуйте совет от майкрософта http://windows.microsoft.com/ru-ru/windows/fix-corrupted-user-profile

Да все нормально, я против твоих домыслов ничего не имею, есть как есть, пацан просил, надо было ему помочь, я дал варианты решения (если надо разложу), у тебя другие есть? Есть, выкладывай конкретно, не только ему одному помогут, нас тут много.....

А че только кнопки 2-е )), а не 3-и - два "лэйбла" плюс сама кнопуля, одна область приема message. А в остальном сколько стилей - столько отрисовок. А у тебя в исходниках сколько стилей отрисовывает текст выше картинки?

Хорошо. Кстати поддерживаемый Racheengel вариант 2  не подразумевает или "закалебет" поддержку QSS, так же как и ваш . По большому счету в.1. самый верный, но тут, если углубиться в исходники, виноваты сами разрабы, что не выделили текст и картинку в отдельные элементы.

Визуально в чем проявляется убожество?

Есть 3 варианта.
1. Переписать drawItemText и drawItemPixmap наследовавшись от QProxyStyle.
2. Переписать paintEvent наследовавшись от QToolButton.
3. В конструкторе формы создать layout с двумя QLable для каждой кнопки.

Я бы выбрал 3-й вариант, он будет содержать ~40 строк кода и простоту понимания в отличие от других вариантов, содержащих ~140 строк кода из которых 95% будет повторять исходники Qt.

Для того что бы купить новый проц, а это незапланированные расходы пусть даже проц стоит 3 бакса нужно обоснование: несколько математиков, программистов, электронников, технологов, юристов, маркетинг)))))))))

Узкоспециализированная задача))): был расчет для некого гироскопа на неком проце, медленно работал, оптимизация расчета заняла 2 месяца, руководство послало нахер всех математиков и купила новый проц

Когда то в давние времена типа синклер и айбиэм часто применяли "асм"- вставки, которые повышали скорострельность), но с последующим выпуском турбоси и его привязки к процу вставки стали тормозить из-за оптимизации и можно было восхищаться разработчиками компиллеров. А сей час же питон, ява, руби, пихапи и др. выполняют то же самое но чуть дольше и нашим юзерам это визуально незаметно, пусть вместо 0.3 сек задача будет висеть 0.7, да и Х. с ним. Для больших задач в 30 мин. оптимизация снизит до 23 мин - ну и Х. с ним, скажут наши заказчики. А оптимиза стоит денег.
Кстати о ностальгии во вложении, наверняка у кого то есть круче))

Очень часто некоторым студентам ставлю хорошую оценку без решения задачи, только за один единственный вопрос: а зачем нужен такой алгоритм, если он оптимизирует задачу на ~0.5%. К примеру: есть функция memset, надо 128kB заполнить быстрее чем эта функция. А надо ли учить их оптимизации с учетом быстродействия современных вычислительных систем?

А кому нужен метод GetOwner? В прочих участках программы мы всегда будем получать 0. А id владельца только в секции lock. Зачем вообще этот класс?