Transparence + curseur
cs_andolini
Messages postés
5
Date d'inscription
vendredi 10 décembre 2004
Statut
Membre
Dernière intervention
16 février 2005
-
10 févr. 2005 à 01:37
desastreux Messages postés 50 Date d'inscription mardi 30 mars 2004 Statut Membre Dernière intervention 5 août 2009 - 13 août 2005 à 15:41
desastreux Messages postés 50 Date d'inscription mardi 30 mars 2004 Statut Membre Dernière intervention 5 août 2009 - 13 août 2005 à 15:41
A voir également:
- Transparence + curseur
- Curseur sql - Conseils pratiques -SQL
- Curseur désolé - Forum Delphi / Pascal
- Curseur - Forum C / C++ / C++.NET
- Super curseur ✓ - Forum Visual Basic
- Curseur mysql ✓ - Forum SQL
1 réponse
desastreux
Messages postés
50
Date d'inscription
mardi 30 mars 2004
Statut
Membre
Dernière intervention
5 août 2009
13 août 2005 à 15:41
13 août 2005 à 15:41
Pour la transparence d'une fenêtre en JAVA, pas trop d'illusions,
mais y a peut-être déjà un début de solution sur :
http://www.javafr.com/forum.v2.aspx?id=181501
Pour le Thread.sleep(), ça me paraît tout à fait logique avec quelques bases "Hardware" :
On peut donner aux threads/handles des priorités par thread, voir
par threadPool, certes, mais en cas de priorité identique, c'est le
processeur qui décide de façon aléatoire celui qu'il doit géré en
premier...
Sachant cela, il suffit que les piles ( rapidité de traitement ) du
processeurs ne soient pas exactement les même, ou que d'autres
applications tournent en simultanné lors des tests, pour que le
.Sleep() donne un temps de réponse différent : En fait, le thread a
bien dormi le temps demandé tant que le processeur lui était consacré...
Mais en plus de ce temps là, pour la réponse attendue, il faut rajouter
le temps pris par les autres threads utilisés en même temps par la
machine ( pour Windows, etc... ) : C'est le but des threads que de
multiplier les requêtes pour obtenir la meilleur performance possible
en cadence-processeur, mais ceux-ci restent limités !
Sur de gros processeurs, le passage d'un thread à un autre, ça frise le
négligeable, mais prends de gros jeux gourmands en ressources (
réseaux, graphismes,... ) où les threads nécéssitent l'utilisation MAX
d'autres ressources ( RAM, ... ) et de petits processeurs et là; le
phénomène est tellement amplifié que tu es parfois obligé de couper ton
antivirus pour pouvoir jouer plus décemment...
mais y a peut-être déjà un début de solution sur :
http://www.javafr.com/forum.v2.aspx?id=181501
Pour le Thread.sleep(), ça me paraît tout à fait logique avec quelques bases "Hardware" :
On peut donner aux threads/handles des priorités par thread, voir
par threadPool, certes, mais en cas de priorité identique, c'est le
processeur qui décide de façon aléatoire celui qu'il doit géré en
premier...
Sachant cela, il suffit que les piles ( rapidité de traitement ) du
processeurs ne soient pas exactement les même, ou que d'autres
applications tournent en simultanné lors des tests, pour que le
.Sleep() donne un temps de réponse différent : En fait, le thread a
bien dormi le temps demandé tant que le processeur lui était consacré...
Mais en plus de ce temps là, pour la réponse attendue, il faut rajouter
le temps pris par les autres threads utilisés en même temps par la
machine ( pour Windows, etc... ) : C'est le but des threads que de
multiplier les requêtes pour obtenir la meilleur performance possible
en cadence-processeur, mais ceux-ci restent limités !
Sur de gros processeurs, le passage d'un thread à un autre, ça frise le
négligeable, mais prends de gros jeux gourmands en ressources (
réseaux, graphismes,... ) où les threads nécéssitent l'utilisation MAX
d'autres ressources ( RAM, ... ) et de petits processeurs et là; le
phénomène est tellement amplifié que tu es parfois obligé de couper ton
antivirus pour pouvoir jouer plus décemment...
