Quando l'utente acquisisce un angolo di una finestra ridimensionabile e quindi lo sposta, Windows sposta dapprima il contenuto della finestra, quindi emette un WM_SIZE sulla finestra da ridimensionare.Come faccio a forzare Windows a non ridisegnare nulla nella mia finestra di dialogo quando l'utente sta ridimensionando la mia finestra di dialogo?
Così, in una finestra di dialogo in cui voglio controllare il movimento di vari controlli figlio, e voglio eliminare lo sfarfallio, l'utente prima vede quale sistema operativo Windows pensa che la finestra avrà l'aspetto (perché, AFAICT, il sistema operativo usa un approccio bitblt allo spostamento di cose all'interno della finestra prima di inviare WM_SIZE) - e solo poi la mia finestra di dialogo può gestire lo spostamento dei suoi controlli figli, o ridimensionarli, ecc., dopo di che deve forzare le cose a ridisegnare, che ora causa sfarfallio (per lo meno).
La mia domanda principale è: C'è un modo per forzare Windows a non fare questa stupida cosa amara? Sicuramente sarà sbagliato nel caso di una finestra con controlli che si muovono man mano che la finestra viene ridimensionata, o che si ridimensionano come il loro genitore viene ridimensionato. In entrambi i casi, avendo il sistema operativo fare una pre-vernice, basta avvitare i lavori.
Ho pensato per un momento che potrebbe essere correlato ai flag di classe CS_HREDRAW e CSVREDRAW. Tuttavia, la realtà è che non voglio che il sistema operativo mi chieda di cancellare la finestra - voglio solo ridipingere me stesso senza che il sistema operativo modifichi prima il contenuto della mia finestra (cioè voglio che il display sia quello che era prima che l'utente iniziasse il ridimensionamento, senza alcun bitblit dal sistema operativo). E io non voglio che il sistema operativo di dire ogni controllo che ha bisogno di essere ridisegnato o (a meno che non è capitato di essere uno che è stato di fatto oscurato o rivelato dalla ridimensionamento
Quello che voglio veramente:.
- Per spostare & ridimensionamento bambini controlli prima nulla viene aggiornato sullo schermo.
- disegnare tutti del bambino spostati o ridimensionati controlla completamente in modo che appaiano senza artefatti alla loro nuova dimensione & posizione.
- Disegna gli spazi tra i controlli figlio senza influire sui controlli secondari.
NOTA: i passaggi 2 e 3 potrebbero essere invertiti.
Le tre cose sopra riportate si verificano correttamente quando utilizzo DeferSetWindowPos() in combinazione con la risorsa di dialogo contrassegnata come WS_CLIPCHILDREN.
Avrei un ulteriore piccolo vantaggio se potessi fare quanto sopra a un controller di memoria, e quindi fare solo un singolo bitblt alla fine del gestore WM_SIZE.
Ho giocato con questo per un po 'di tempo, e non posso scappare due cose:
io sono ancora in grado di sopprimere Windows da fare un 'bitblt predittivo'. Risposta: vedere sotto per una soluzione che sovrascriva WM_NCCALCSIZE per disabilitare questo comportamento.
Non riesco a vedere come si possa costruire una finestra di dialogo in cui il figlio controlla un doppio buffer. Risposta: Vedere la risposta di John (contrassegnata come risposta) di seguito per come chiedere al sistema operativo Windows di raddoppiare il buffer della finestra di dialogo (nota: questa operazione non consente l'uso di GetDC() tra le operazioni di disegno, in base ai documenti).
La mia soluzione finale (Grazie a tutti coloro che hanno contribuito, specialmente John K..):
Dopo tanto sudore e lacrime, ho trovato che la seguente tecnica funziona perfettamente, sia in Aero e in XP o con Aero disabilitato. Il flicking è inesistente (1).
- Aggancia la finestra di dialogo proc.
- Ignora WM_NCCALCSIZE per forzare Windows a convalidare l'intera area client e non bitblt.
- Ignora WM_SIZE per eseguire tutte le tue mosse & ridimensiona utilizzando BeginDeferWindowPos/DeferWindowPos/EndDeferWindowPos per tutte le finestre visibili.
- Assicurarsi che la finestra di dialogo abbia lo stile WS_CLIPCHILDREN.
- NON utilizzare CS_HREDRAW | CS_VREDRAW (le finestre di dialogo non lo fanno, quindi in genere non è un problema).
Il codice di layout è a vostra discrezione, è abbastanza facile trovare esempi su CodeGuru o CodeProject di gestori di layout o eseguire il rollover.
Ecco alcuni stralci di codice che dovrebbe ottenere la maggior parte del modo:
LRESULT ResizeManager::WinProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam)
{
switch (msg)
{
case WM_ENTERSIZEMOVE:
m_bResizeOrMove = true;
break;
case WM_NCCALCSIZE:
// The WM_NCCALCSIZE idea was given to me by John Knoeller:
// see: http://stackoverflow.com/questions/2165759/how-do-i-force-windows-not-to-redraw-anything-in-my-dialog-when-the-user-is-resiz
//
// The default implementation is to simply return zero (0).
//
// The MSDN docs indicate that this causes Windows to automatically move all of the child controls to follow the client's origin
// and experience shows that it bitblts the window's contents before we get a WM_SIZE.
// Hence, our child controls have been moved, everything has been painted at its new position, then we get a WM_SIZE.
//
// Instead, we calculate the correct client rect for our new size or position, and simply tell windows to preserve this (don't repaint it)
// and then we execute a new layout of our child controls during the WM_SIZE handler, using DeferWindowPos to ensure that everything
// is moved, sized, and drawn in one go, minimizing any potential flicker (it has to be drawn once, over the top at its new layout, at a minimum).
//
// It is important to note that we must move all controls. We short-circuit the normal Windows logic that moves our child controls for us.
//
// Other notes:
// Simply zeroing out the source and destination client rectangles (rgrc[1] and rgrc[2]) simply causes Windows
// to invalidate the entire client area, exacerbating the flicker problem.
//
// If we return anything but zero (0), we absolutely must have set up rgrc[0] to be the correct client rect for the new size/location
// otherwise Windows sees our client rect as being equal to our proposed window rect, and from that point forward we're missing our non-client frame
// only override this if we're handling a resize or move (I am currently unaware of how to distinguish between them)
// though it may be adequate to test for wparam != 0, as we are
if (bool bCalcValidRects = wparam && m_bResizeOrMove)
{
NCCALCSIZE_PARAMS * nccs_params = (NCCALCSIZE_PARAMS *)lparam;
// ask the base implementation to compute the client coordinates from the window coordinates (destination rect)
m_ResizeHook.BaseProc(hwnd, msg, FALSE, (LPARAM)&nccs_params->rgrc[0]);
// make the source & target the same (don't bitblt anything)
// NOTE: we need the target to be the entire new client rectangle, because we want windows to perceive it as being valid (not in need of painting)
nccs_params->rgrc[1] = nccs_params->rgrc[2];
// we need to ensure that we tell windows to preserve the client area we specified
// if I read the docs correctly, then no bitblt should occur (at the very least, its a benign bitblt since it is from/to the same place)
return WVR_ALIGNLEFT|WVR_ALIGNTOP;
}
break;
case WM_SIZE:
ASSERT(m_bResizeOrMove);
Resize(hwnd, LOWORD(lparam), HIWORD(lparam));
break;
case WM_EXITSIZEMOVE:
m_bResizeOrMove = false;
break;
}
return m_ResizeHook.BaseProc(hwnd, msg, wparam, lparam);
}
Il ridimensionamento è davvero fatto dal membro Resize(), in questo modo:
// execute the resizing of all controls
void ResizeManager::Resize(HWND hwnd, long cx, long cy)
{
// defer the moves & resizes for all visible controls
HDWP hdwp = BeginDeferWindowPos(m_resizables.size());
ASSERT(hdwp);
// reposition everything without doing any drawing!
for (ResizeAgentVector::const_iterator it = m_resizables.begin(), end = m_resizables.end(); it != end; ++it)
VERIFY(hdwp == it->Reposition(hdwp, cx, cy));
// now, do all of the moves & resizes at once
VERIFY(EndDeferWindowPos(hdwp));
}
E forse il po 'complicato finale può essere visto in Riposizionare del ResizeAgent() gestore:
HDWP ResizeManager::ResizeAgent::Reposition(HDWP hdwp, long cx, long cy) const
{
// can't very well move things that no longer exist
if (!IsWindow(hwndControl))
return hdwp;
// calculate our new rect
const long left = IsFloatLeft() ? cx - offset.left : offset.left;
const long right = IsFloatRight() ? cx - offset.right : offset.right;
const long top = IsFloatTop() ? cy - offset.top : offset.top;
const long bottom = IsFloatBottom() ? cy - offset.bottom : offset.bottom;
// compute height & width
const long width = right - left;
const long height = bottom - top;
// we can defer it only if it is visible
if (IsWindowVisible(hwndControl))
return ::DeferWindowPos(hdwp, hwndControl, NULL, left, top, width, height, SWP_NOZORDER|SWP_NOACTIVATE);
// do it immediately for an invisible window
MoveWindow(hwndControl, left, top, width, height, FALSE);
// indicate that the defer operation should still be valid
return hdwp;
}
il 'ingannevole' essere che evitiamo di rovinare le finestre che sono state distrutte e non proviamo a rimandare un SetWindowPos contro una finestra che non è visibile (poiché ciò è documentato come "fallirà").
Ho testato quanto sopra in un progetto reale che nasconde alcuni controlli e utilizza layout abbastanza complessi con un eccellente successo. C'è zero sfarfallio (1) anche senza Aero, anche quando si ridimensiona usando l'angolo in alto a sinistra della finestra di dialogo (la maggior parte delle finestre ridimensionabili mostrerà il maggior sfarfallio e problemi quando si afferra quel manico - IE, FireFox, ecc.).
Se c'è interesse sufficiente, potrei essere persuaso a modificare i miei risultati con un'implementazione di esempio reale per CodeProject.com o qualcosa di simile. Scrivimi.
(1) Si noti che è impossibile evitare un pareggio sopra a quello che era solito essere lì. Per ogni parte della finestra di dialogo che non è stata modificata, l'utente non può vedere nulla (nessun sfarfallio di sorta). Ma dove le cose sono cambiate, c'è un cambiamento visibile all'utente - questo è impossibile da evitare, ed è una soluzione al 100%.
Questa tecnica non funziona più con Win10 (e probabilmente non funziona con Win8). Triste. Siamo di nuovo a guardare i controlli "camminano" attraverso lo schermo fino a dove dovrebbero essere, invece di saltare istantaneamente nella loro posizione corretta. – Mordachai
Dato che hai chiesto, certo, mi piacerebbe vedere un'implementazione di esempio reale. Questo è qualcosa che mi interessa, specialmente se si tratta di una soluzione completa winapi (cioè non MFC). Anche MFC sarebbe interessante da leggere. Eventuali aggiornamenti per Windows 10? – jrh
@jrh Tristemente, Windows 8+ ha infranto questa tecnica, e non sono stato ispirato a capire come farlo funzionare di nuovo (se è anche possibile). Quanto sopra ha funzionato da XP, Vista, Win 7. Ma 8+ lo rende semplicemente stupido come lo era senza tutto questo sforzo. – Mordachai