On Thursday, January 17, 2013 08:04:14 Martin Gräßlin wrote: > So my suggestion is to send updates for needed thumbnails together with the > damage events. We have to look into how we can achieve it, but it would > bring some advantages: > * existing code path inside KWin can be reused > * thumbnail is always the latest version > * no memory read-backs from GPU > * if thumbnail is not needed (because area is not rendered) it can be > discarded
sounds good, particularly as it would keep all the UI interaction in the host application (e.g. the shell). as you noted, it would need to be *fast* as that was one problem we had in the past with "kwin renders the thumbnails, but the UI is managed in the host application": the UI would update/change and the thumbnail painting would be out of sync with it. this was particularly visible when there was custom chrome around the thumbnail, such as the close button in Active's Peek area. in fact, that is probably still a problem: the close button needs to be placed visually next to the thumbnail, which means the UI needs to know the thumbnail geometry. i dislike the idea of trying to coordinate that geometry placement between two processes (it's the same genre of problem we have right now), so the chrome should be rendered with the thumbnail itself. .. but then we have the issue of thumbnails of different sizes (widths, most often, as we tend to show them in horizontal rows right now). not all windows will thumbnail to the same size, and showing those in a row means spacing between items will be (visually) different. in QML terms, the perfect solution would be an item than knows the geometry of the thumbnail it will be rendering, and then all of the above problems go away. but if that QML item is not in kwin (something that should be avoided), that implies making information available from kwin about thumbnail sizes for specific windows. (and all this to ensure that we have fluidly updating thumbnails ...) -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
