Bonjour =E0 tous,
je cherche un gestionnaire d'affichage =ABtransparent=BB ou=20
=ABvirtuel=BB pour pouvoir tr=E8s rapidement passer d'un programme =E0=20
l'autre ( genre =ABDesqView=BB pour msdos, sous lequel tournait=20
windoze ... si je peux oser la comparaison ? ).
Explication :
Certains programmes sont tr=E8s gourmands en ressources CPU, et=20
je veux les faire tourner en arri=E8re-plan, pendant que j'ex=E9cute=20
d'autres programmes, et aller voir de temps =E0 autre o=F9 ils en=20
sont. Avec le gestionnaire d'affichage standard de KDE (=20
XFree86 ? ), quand je passe d'un programme =E0 l'autre, un signal=20
est envoy=E9 au programme:=ABredessine-toi=BB( comme sous windoze), ce=20
qui est parfois extr=E8mement lent, puisque c'est le programme=20
soi-m=EAme qui doit reconstruire l'affichage. Ce que je cherche est=20
un gestionnaire d'affichage qui stocke l'affichage au fur et =E0=20
mesure que le(s) programme(s) se d=E9roule(nt), et lorsqu'on=20
demande =E0 voir, affiche "quasi instantan=E9ment" la situation=20
actuelle, car ce n'est pas le programme lui-m=EAme qui doit se=20
=ABredessiner=BB mais le programme d'affichage qui recopie=20
simplement=BB la =ABm=E9moire video virtuelle=BB dans la m=E9moire d'=E9c=
ran.=20
Ainsi les programme gourmands peuvent tourner en basse priorit=E9,=20
et l'affichage =EAtre tr=E8s rapide. C'est ce que faisait le=20
gestionnaire multi-t=E2che DeskView il y a 10 ans d=E9j=E0...=20
Qui peut me dire quel est l'=E9quivalent de DesqView pour Linux=20
( avec paquet Debian de pr=E9f=E9rence, si possible )? J'ai cherch=E9=20
dans les descriptions, mais j'ai pas trouv=E9 [ j'ai sans doute pas=20
tout compris non plus]
Je vous remercie =E0 l'avance.
Patrick
--=20
Patrick Carabin.
=ABPlant in de tuin van je hart slechts de roos der liefde=BB
=ABDans le jardin de ton coeur, ne plante que la rose d' amour=BB
=09=09=09=09=09=09Baha'u'llah.
C'est vrai. Le seul reproche que je puisse faire au pilote 'nv' c'est la non-implémentation du module XVideo d'XFree permettant un affichage accéléré de la vidéo et des fonctions de zoom/incrustation sans bouffer le cpu.
Sinon c'est vrai qu'en 2D, il a des perfs correctes par rapport au module proprio 'nvidia'.
Cela n'empêche pas que sans le drivers proprio l'affichage est lent quand tu déplaces des fenêtres ou que tu cliques sur un menu.
-- Pierre-Selim Huard
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Damien Raude-Morvan a écrit :
C'est vrai. Le seul reproche que je puisse faire au pilote 'nv' c'est la
non-implémentation du module XVideo d'XFree permettant un affichage accéléré
de la vidéo et des fonctions de zoom/incrustation sans bouffer le cpu.
Sinon c'est vrai qu'en 2D, il a des perfs correctes par rapport au module
proprio 'nvidia'.
Cela n'empêche pas que sans le drivers proprio l'affichage est lent
quand tu déplaces des fenêtres ou que tu cliques sur un menu.
--
Pierre-Selim Huard
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
C'est vrai. Le seul reproche que je puisse faire au pilote 'nv' c'est la non-implémentation du module XVideo d'XFree permettant un affichage accéléré de la vidéo et des fonctions de zoom/incrustation sans bouffer le cpu.
Sinon c'est vrai qu'en 2D, il a des perfs correctes par rapport au module proprio 'nvidia'.
Cela n'empêche pas que sans le drivers proprio l'affichage est lent quand tu déplaces des fenêtres ou que tu cliques sur un menu.
-- Pierre-Selim Huard
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Sylvain Sauvage
Tue, 22 Jun 2004 06:17:28 +0200, Patrick Carabin a écrit :
Le Vendredi 18 Juin 2004 16:09, Sylvain Sauvage a écrit : > Fri, 18 Jun 2004 15:19:23 +0200, Patrick Carabin a écrit : > >[...] > > Je vois une option « virtual » et une option « > > screen » qui pourraient être ça, sinon « fvwm » > > pourrait aussi correspondre à ce que je cherche, mais > > je n'ai trouvé jusqu'à présent qu'une doc en Angliche, > > et comme d'habitude écrite probablement par des > > non-anglophones, donc douteuse... Je vais chercher + > > loin, merci pour les idées! > > Je ne pense pas. > En fait, le problème que tu as c'est que lorsqu'une > fenêtre devient visible, elle reçoit un évènement qui > l'en informe. Donc, si le programme à qui appartient > cette fenêtre gère cet évènement, il redessine le contenu > de la fenêtre. > Pour éviter cela, il faut donc que le programme ne > relance pas le réaffichage complet et n'arrête pas son > calcul lorsqu'il reçoit l'évènement (il doit soit ignorer > l'évènement, soit faire du double-buffering). > Maintenant, tu peux trouver un gestionnaire de fenêtres > qui conserve lui-même une copie (le fameux swap dont il a > été question dans ce fil) de la fenêtre et qui évite de > lancer des évènements à tout bout de champ. Le problème > qui se pose alors est : Comment le contenu de cette copie > est-elle donc modifiée par l'application ? Il faut que > l'application puisse prévenir le gestionnaire de > fenêtres... > Le principe est que l'application ignore si oui ou non elle est effectivement visible: elle se croit TOUJOURS visible, et s'affiche là où on lui a dit de s'afficher, elle n'a pas à savoir si ce técran correspond à l'écran réel ou est simplement virtuel pour l'application, jécran nest jamais qu'une zone en mémoire... C'est le gestionnaire X qui doit assurer la correspondance entre l'écran réel et ( une portion de ) l'écran virtuel. C'est d'ailleurs ce qui se passe avec certaines cartes gaphiques, ans les limites de leur mémoire et des modes qu'elles savent gérer, et avec les inconvénients qui en découlent. Si l'affichage virtuel est géré par X ( et non plus par la carte video ), l'affichage virtuel devient possible avec toutes les cartes gaphiques et tous les écrans, et n'est plus limité que par la mémoire centrale disponible
Note : j'utilise moi-même fvwm depuis un long moment.
Ce que je voulais dire, c'est que le gestionnaire de fenêtres envoie toujours des événements à la fenêtre lorsqu'elle devient visible (il suffit de faire un essai avec xev : lorsque l'on change d'écran et que l'on revient, la fenêtre reçoit des événements VisibilityNotify et Expose). Ces événements surviennent toujours, même lorsque la fenêt re n'a pas le focus.
Donc Fvwm n'est pas une solution si le programme s'intéresse à ces événements et relance son affichage complet lorsqu'il les reçoit.
-- Sylvain Sauvage
Tue, 22 Jun 2004 06:17:28 +0200, Patrick Carabin a écrit :
Le Vendredi 18 Juin 2004 16:09, Sylvain Sauvage a écrit :
> Fri, 18 Jun 2004 15:19:23 +0200, Patrick Carabin a écrit :
> >[...]
> > Je vois une option « virtual » et une option «
> > screen » qui pourraient être ça, sinon « fvwm »
> > pourrait aussi correspondre à ce que je cherche, mais
> > je n'ai trouvé jusqu'à présent qu'une doc en Angliche,
> > et comme d'habitude écrite probablement par des
> > non-anglophones, donc douteuse... Je vais chercher +
> > loin, merci pour les idées!
>
> Je ne pense pas.
> En fait, le problème que tu as c'est que lorsqu'une
> fenêtre devient visible, elle reçoit un évènement qui
> l'en informe. Donc, si le programme à qui appartient
> cette fenêtre gère cet évènement, il redessine le contenu
> de la fenêtre.
> Pour éviter cela, il faut donc que le programme ne
> relance pas le réaffichage complet et n'arrête pas son
> calcul lorsqu'il reçoit l'évènement (il doit soit ignorer
> l'évènement, soit faire du double-buffering).
> Maintenant, tu peux trouver un gestionnaire de fenêtres
> qui conserve lui-même une copie (le fameux swap dont il a
> été question dans ce fil) de la fenêtre et qui évite de
> lancer des évènements à tout bout de champ. Le problème
> qui se pose alors est : Comment le contenu de cette copie
> est-elle donc modifiée par l'application ? Il faut que
> l'application puisse prévenir le gestionnaire de
> fenêtres...
>
Le principe est que l'application ignore si oui ou non
elle est effectivement visible: elle se croit TOUJOURS
visible, et s'affiche là où on lui a dit de s'afficher,
elle n'a pas à savoir si ce técran correspond à l'écran
réel ou est simplement virtuel pour l'application, jécran
nest jamais qu'une zone en mémoire... C'est le gestionnaire
X qui doit assurer la correspondance entre l'écran réel et
( une portion de ) l'écran virtuel. C'est d'ailleurs ce qui
se passe avec certaines cartes gaphiques, ans les limites
de leur mémoire et des modes qu'elles savent gérer, et avec
les inconvénients qui en découlent. Si l'affichage virtuel
est géré par X ( et non plus par la carte video ),
l'affichage virtuel devient possible avec toutes les cartes
gaphiques et tous les écrans, et n'est plus limité que par
la mémoire centrale disponible
Note : j'utilise moi-même fvwm depuis un long moment.
Ce que je voulais dire, c'est que le gestionnaire de fenêtres envoie
toujours des événements à la fenêtre lorsqu'elle devient visible (il
suffit de faire un essai avec xev : lorsque l'on change d'écran et que
l'on revient, la fenêtre reçoit des événements VisibilityNotify et
Expose). Ces événements surviennent toujours, même lorsque la fenêt re n'a
pas le focus.
Donc Fvwm n'est pas une solution si le programme s'intéresse à ces
événements et relance son affichage complet lorsqu'il les reçoit.
Tue, 22 Jun 2004 06:17:28 +0200, Patrick Carabin a écrit :
Le Vendredi 18 Juin 2004 16:09, Sylvain Sauvage a écrit : > Fri, 18 Jun 2004 15:19:23 +0200, Patrick Carabin a écrit : > >[...] > > Je vois une option « virtual » et une option « > > screen » qui pourraient être ça, sinon « fvwm » > > pourrait aussi correspondre à ce que je cherche, mais > > je n'ai trouvé jusqu'à présent qu'une doc en Angliche, > > et comme d'habitude écrite probablement par des > > non-anglophones, donc douteuse... Je vais chercher + > > loin, merci pour les idées! > > Je ne pense pas. > En fait, le problème que tu as c'est que lorsqu'une > fenêtre devient visible, elle reçoit un évènement qui > l'en informe. Donc, si le programme à qui appartient > cette fenêtre gère cet évènement, il redessine le contenu > de la fenêtre. > Pour éviter cela, il faut donc que le programme ne > relance pas le réaffichage complet et n'arrête pas son > calcul lorsqu'il reçoit l'évènement (il doit soit ignorer > l'évènement, soit faire du double-buffering). > Maintenant, tu peux trouver un gestionnaire de fenêtres > qui conserve lui-même une copie (le fameux swap dont il a > été question dans ce fil) de la fenêtre et qui évite de > lancer des évènements à tout bout de champ. Le problème > qui se pose alors est : Comment le contenu de cette copie > est-elle donc modifiée par l'application ? Il faut que > l'application puisse prévenir le gestionnaire de > fenêtres... > Le principe est que l'application ignore si oui ou non elle est effectivement visible: elle se croit TOUJOURS visible, et s'affiche là où on lui a dit de s'afficher, elle n'a pas à savoir si ce técran correspond à l'écran réel ou est simplement virtuel pour l'application, jécran nest jamais qu'une zone en mémoire... C'est le gestionnaire X qui doit assurer la correspondance entre l'écran réel et ( une portion de ) l'écran virtuel. C'est d'ailleurs ce qui se passe avec certaines cartes gaphiques, ans les limites de leur mémoire et des modes qu'elles savent gérer, et avec les inconvénients qui en découlent. Si l'affichage virtuel est géré par X ( et non plus par la carte video ), l'affichage virtuel devient possible avec toutes les cartes gaphiques et tous les écrans, et n'est plus limité que par la mémoire centrale disponible
Note : j'utilise moi-même fvwm depuis un long moment.
Ce que je voulais dire, c'est que le gestionnaire de fenêtres envoie toujours des événements à la fenêtre lorsqu'elle devient visible (il suffit de faire un essai avec xev : lorsque l'on change d'écran et que l'on revient, la fenêtre reçoit des événements VisibilityNotify et Expose). Ces événements surviennent toujours, même lorsque la fenêt re n'a pas le focus.
Donc Fvwm n'est pas une solution si le programme s'intéresse à ces événements et relance son affichage complet lorsqu'il les reçoit.
-- Sylvain Sauvage
Patrick Carabin
Le Mercredi 23 Juin 2004 12:28, Sylvain Sauvage a écrit :
Note : j'utilise moi-même fvwm depuis un long moment.
Ce que je voulais dire, c'est que le gestionnaire de fenêtres envoie toujours des événements à la fenêtre lorsqu'elle devient visible (il suffit de faire un essai avec xev : lorsque l'on change d'écran et que l'on revient, la fenêtre reçoit des événements VisibilityNotify et Expose). Ces événements surviennent toujours, même lorsque la fenêtre n'a pas le focus.
Donc Fvwm n'est pas une solution si le programme s'intéresse à ces événements et relance son affichage complet lorsqu'il les reçoit.
Merci beaucoup pour cette information précieuse. Je sais donc maintenant que fvwm, en dehors de son intérêt par ailleurs, n'est pas la solution à mon problème --
Patrick Carabin.
«Plant in de tuin van je hart slechts de roos der liefde» «Dans le jardin de ton coeur, ne plante que la rose d' amour» Baha'u'llah.
Le Mercredi 23 Juin 2004 12:28, Sylvain Sauvage a écrit :
Note : j'utilise moi-même fvwm depuis un long moment.
Ce que je voulais dire, c'est que le gestionnaire de fenêtres
envoie toujours des événements à la fenêtre lorsqu'elle devient
visible (il suffit de faire un essai avec xev : lorsque l'on
change d'écran et que l'on revient, la fenêtre reçoit des
événements VisibilityNotify et Expose). Ces événements
surviennent toujours, même lorsque la fenêtre n'a pas le focus.
Donc Fvwm n'est pas une solution si le programme s'intéresse à
ces événements et relance son affichage complet lorsqu'il les
reçoit.
Merci beaucoup pour cette information précieuse. Je sais donc
maintenant que fvwm, en dehors de son intérêt par ailleurs, n'est
pas la solution à mon problème
--
Patrick Carabin.
«Plant in de tuin van je hart slechts de roos der liefde»
«Dans le jardin de ton coeur, ne plante que la rose d' amour»
Baha'u'llah.
Le Mercredi 23 Juin 2004 12:28, Sylvain Sauvage a écrit :
Note : j'utilise moi-même fvwm depuis un long moment.
Ce que je voulais dire, c'est que le gestionnaire de fenêtres envoie toujours des événements à la fenêtre lorsqu'elle devient visible (il suffit de faire un essai avec xev : lorsque l'on change d'écran et que l'on revient, la fenêtre reçoit des événements VisibilityNotify et Expose). Ces événements surviennent toujours, même lorsque la fenêtre n'a pas le focus.
Donc Fvwm n'est pas une solution si le programme s'intéresse à ces événements et relance son affichage complet lorsqu'il les reçoit.
Merci beaucoup pour cette information précieuse. Je sais donc maintenant que fvwm, en dehors de son intérêt par ailleurs, n'est pas la solution à mon problème --
Patrick Carabin.
«Plant in de tuin van je hart slechts de roos der liefde» «Dans le jardin de ton coeur, ne plante que la rose d' amour» Baha'u'llah.
