nspluginviewer priority on newer linux kernel

[koos vriezen]

2007/8/16, James Richard Tyrer <tyrerj at acm.org>:
> koos vriezen wrote:
> > Using either a timer signal or a timeout, you don't need input to jump
> > out of this listening state.
>
> But you said that X11 programs nicely wait.

Yes else they would consume 100% CPU like old DOS or Win31/W95 did.

> >>>> You could improve this situation with multiple threads.  A small thread
> >>>> accepting the input and doing the GUI menus and controlling a large
> >>>> thread which actually does the work.  I have no idea how this would (or
> >>>> could) be implemented in C++ although I am sure I have a text somewhere
> >>>> that explains how to do it in a procedural language.
> >>> More non-sense ..
> >> Yes, this is all nonsense.  <sarcasm> The problem doesn't exist so we
> >> shouldn't do anything about it.</sarcasm>
> >
> > I simply don't see what 'improving input' has to do with improving the
> > situation.
>
> The problem is that input is being blocked by running processes.  So, it
> is an input issue.  You need to find a way to prevent what should be
> background processes from blocking execution in the window that has focus.

That is the question. Could be blocking DCOP with the plugin. Could be
Xserver using lots of CPU (I one read setting Xserver to -10 would
help). Heavy I/O load is of course a blocker.

> > The flash player on Linux definitely uses too much CPU (comparing to
> > eg. MPlayer playing the same movie) and apparently doesn't handle the
> > cases where it lacks behind timer events in a user experience pleasing
> > way.
>
> I see the problem as the fact that nsplugins (and Flash Player is the
> worst offender) are running and using over half of my CPU and they
> aren't even for the window that has focus.
>
> > (I've added a note on my virtual TODO list whether the flash plugin
> > can be notified about being visible or not)
> >
> >> So, why don't you try it and try to confirm the problem before saying
> >> that it is nonsense.  Open three Konqueror windows with 10 tabs each and
> >> see what happens.  Note that if you have a 3 GHz CPU and 2 GB of memory,
> >> this probably isn't going to happen, KDE should also run on slower
> >> machines with less memory.
> >
> > Yes but if demands are getting higher, so should the hardware. SMP
> > users know this for ages, but multicore really helps.
>
> We should then say what the hardware requirements are. But, it would be
> very un-Linux like to say that you need a dual core running at 2 GHz and
> 2 GB of ram to run KDE.
>
> Multi-core only begs the question.  If you have 4 cores, then you need 4
> processes that shouldn't be running to clog up the works -- it can still
> happen.

I don't think its that easy. Multi core also means IPC goes faster,
which means every X apps can communicate faster w/ the Xserver, doing
faster dbus/dcop calls, dns lookups etc.

> Multi-core is going to work better with multi-threaded processes.

Yes and so multiple processes

Koos