hi all ... currently, whenever there is a window thumbnail on screen, kwin paints it. on plasma desktop, this is currently not a big problem for our default setup since we only use them in tooltips on window listing plasmoids.
in Active, it has been and continues to be more problematic. this is because
we use the thumbnails in an interactive UI: they *are* the window switcher.
after trying other methods that didn't work overly well, the current approach
is that kwin itself draws the entire window selection area and handles some of
the events itself (in theory passing others through). this means that the
"Peak" UI is party drawn and managed by plasma-device and partly by kwin. the
result is ok, but is prone to breakage and we have to be overly careful when
working around that part.
any other usage that might include showing window thumbnails (e.g. the
"Plasmoid object class for QML" thread) also runs into problems.
i don't think it is a scalable, long term solution in which we change the
window manager as needed to accomodate new UIs, such as Active's Peak area,
and insist on visual components knowing their system window ID.
an alternative is to allow passing of pixmap data from kwin to processes like
plasma-device who can then handle the painting themselves.
the pros and cons, as i understand them currently:
KWin Does It All
Pro:
* minimal copying of data
* guaranteed to sync with compositor updates
* can guarantee no process has access to pixmap data (privacy
concern; only interesting on Wayland, however)
Cons:
* requires kwin to provide workspace UI, which then must also
blend
with existing UI outside of kwin
* commits CPU cycles to shell UI in kwin, which should be
focused on
compositing performance and window management for most fluid results
* any thumbnail using component must have access to its system
window id
* requires adjusting how kwin does things if we adjust the
shell UI
(iow: they are quite tightly coupled right now)
KWin Provides Thumbnails:
Pro:
* complete flexibility in how they are presented in workspace UI
* all event handling goes into the application displaying them
Con:
* rendering of thumbnails can only happen as quickly as the
application (e.g. the shell) updates
you can flip most of the Cons into "Pros" for the other solution, but for
brevity i didn't bother :)
also, the privacy issue can be addressed at least in part by kwin only
providing scaled-down thumbnails. it may even be possible to only allow access
to "blessed" processes, though i'm not sure that's entirely realistic.
i would like to see a transition from the current method of "kwin does it all"
to "kwin provides thumbnails", though i do not think it makes any sense to do
so before Workspaces 2 for the following reasons:
* we have other important things to accomplish between now and then; the
current method mostly works, so we can prioritize it down the list
* i don't know if QGraphicsView is up to the task, performance wise, but i
have high hopes for QML scenegraph given what we've seen with it already
but i'd like to work out a gameplan now so we can work towards it in 2013 :)
--
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
