Kevin Krammer posted on Wed, 03 Aug 2011 14:46:31 +0200 as excerpted:
> On Wednesday, 2011-08-03, Duncan wrote:
>> Sergei Andreev posted on Wed, 03 Aug 2011 12:39:01 +0400 as excerpted:
>
>> > And the answer is:
>> > http://www.freehackers.org/thomas/2009/11/10/wonders-from-a-kde-fan-
and-
>> > developer-about-some-kde-design-choices/comment-page-1/#comment-7507
>>
>> Of course it doesn't perform well with each plasmoid as a separate
>> process... because they chose components with that characteristic.
>>
>> That's the point. It was a new thing so they could chose the
>> components they wanted, and [they chose poorly].
>
> Actually no.
> It is mainly a problem of the underlying technology, i.e. embedding one
> process' window into another one's not being very well supported, or at
> least not on X11.
>
> It is less a problem of performance, Konqueror has done plugins
> out-of-process for ever (incidentally making it the only browser to
> survive Flash crashes for years before other browsers changed to that
> model as well).
Valid and interesting point. Not one I've had a lot of direct experience
with since I won't do flash because it's proprietary, in the first place,
but yes, it's valid, and kde has been recognized for it.
> But it clearly showed the limits of the underlying technologies used for
> that, e.g. the embedding process having little to no control over the
> embedded window (other than probably size and position) and embedded
> window having very few means of communicating needs to the host (and
> having two separate and exclusive event processing contexts).
>
> So with basically forced to have all UI portions in the same process,
> running the data processing in separate execution units might be
> possible in some occasions without dragging down performance too much
> (as indicated by Aaron in the linked comment).
I can't argue with that, either.
But what about the other bit, where I suggested (rewording a bit) that
(1), a natural process subdivision would be at the container level, that
(2), while a whole individual panel or desktop container crashing
wouldn't be as good as limiting it to an individual plasmoid, it'd
certainly be far better than all of plasma including all panels, all
desktops and all activities coming down at once, thus significantly
limiting the damage, that (3), given existing behavior both with effects
on and with them off, separate container processes each with their own
window would behave very little differently in terms of composite, etc,
and (4), that inter-container/inter-process communication could be
reasonably limited without affecting performance /that/ drastically,
while at the same time, /drastically/ improving robustness, just as it
has with the separate krunner and as it does currently when for example
using plasmoidviewer or plasma-windowed for plasmoid-development or the
like.
It seems to be that would be a reasonable compromise, bypassing both the
worst of the stability problems by limiting crashes to a single
container, and the worst of the performance problems, because each
container would then be its own window.
The user experience I have establishing this includes running a separate
superkaramba instance, set to top-dock so it's very nearly replacing an
entire plasma panel. It's /very/ nice to have that still running when
plasma itself crashes or I shut it down and restart it. Given that as
I'm using it, it's almost replacing a full plasma panel... I still have a
systray/notifier plasmoid on a short panel at the end... the concept has
certainly been demonstrated to be effective here, and I'd very dearly
love to see each plasma desktop (two monitors, separately configured
wallpaper and plasmoids, separately crashing would be nice...) and each
panel independent of the others process- and crash-wise, just as my
superkaramba panel is independent of plasma.
As proposed, IPC could be used between desktop and panels for drag-n-drop
integration, etc, probably implemented using dbus, and the performance
hit shouldn't be any more critical than it is when dragging something
between say dolphin and a folderview plasmoid. Yet robustness would be
HUGELY improved, because each panel and each desktop would survive a
lockup or crash of one of the others.
...
Meanwhile, I did notice that the link mentioned konsole as suffering from
a similar issue at the time, all konsole windows belonging to a single
process. That has apparently been fixed for some time, since at least
4.5 I'd guess if not 4.3 or 4.4, as I routinely see multiple konsole
processes and double-checked after reading the discussion -- using the
xkill hotkey only kills the one konsole window, not all of them as it did
back then. =:^)
Now if I could only kill one plasma panel/desktop/container at a time...
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
