Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre actif
    Problème d'affichage avec la nouvelle version Java
    Bonjour,

    je développe un jeu vidéo dans lequel l'affichage des personnages se fait par superposition de couches de peau ou de vêtements colorées.

    Depuis l'installation de la nouvelle version de Java, j'ai ce genre affichage , dont les couleurs sont affreuses et surtout mal affichées :



    A quoi est-ce dû, avez vous déjà vu ce genre de bug ?

    Le principe d'affichage que j'utilise est le suivant :

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    Pour chaque couche à afficher (du corps aux vêtements les plus extérieurs) {
     
    dessinerVersionNoirEtBlanc();
    ajouterMasqueCouleur();
     
    FinPour}


    Donc pour chaque couche, je dessine d'abord une base noir et blanc de l'image à colorer. Puis je crée un rectangle de la couleur à afficher. Je masque ce rectangle avec la couche alpha du vêtement et je superpose cette image en utilisant une combinaison de bits.

    Habituellement, avec les anciennes version, les couleurs sont douces, là on dirait qu'il applique un négatif de la couleur au dessus de certains seuils.

    Je n'arrive pas à comprendre, les spécifications ont-elle été modifiées ou est-ce temporaire ? J'ai vu le même bug chez un ami qui venait d'installer la dernière version de Java.

    Qu'est donc ce bug ?
    __________________________________
    | +
    | Sylvain Tournois - Création logicielle
    |
    | sylv.tournois.free.fr
    |

  2. #2
    Expert éminent sénior
    Ton affichage se fait-il directement sur les composant visibles de la fenetre? Si oui, es-tu bien certain de faire ces opération à l'intérieur du Thread d'affichage? Beaucoup de bug "curieux" concernant les interfaces graphique sont du à des problèmes de concurrence entre un Thread de dessin et le Thread awt qui travaillent en meme temps sur les composants...

    L'idéal pour bien voir le problème serait une partie réduite du code gérant l'affichage et peut etre un screenshot comparatif avec la version "qui fonctionne" de java
    David Delbecq Java developer chez HMS Industrial Networks AB.    LinkedIn | Google+

  3. #3
    Expert éminent
    Salut,

    A tout hasard, tu as essayé en désactivant DirectDraw, avec un petit:

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    -Dsun.java2d.d3d=false


    en paramètre de ta commande java?
    Pour voir...
    "Errare humanum est, sed perseverare diabolicum"

    Ma page sur DVP.com

  4. #4
    Membre actif

    Beaucoup de bug "curieux" concernant les interfaces graphique sont du à des problèmes de concurrence entre un Thread de dessin et le Thread awt qui travaillent en meme temps sur les composants...
    j'ai désactivé le thread d'affichage awt, je suis en monotache sur une JFrame modifiée pour faire du plein écran, donc à priori, ça ne vient pas de là. En plus, sur les anciennes versions de JRE ou JDK, ça fonctionne correctement, c'est dans la dernière version que le bug apparait. J'ai réinstallé une ancienne version et ça fonctionne à nouveau.

    Voici un screenshot qui montre des couleurs plus habituelles :



    Pour le paramètre D3D, je vais essayer, mais ça ne m'emballe pas, je risque d'y perdre en performances, non ?

    Pour la partie de code que je suppose défectueuse, la voici, mais ça fait longtemps que j'y avais pas travaillé :

    La classe contenant la méthode de dessin est une encapsulation d'image avec des paramètres pour la charger au bon moment.
    L'image contenue s'appelle image.
    Le paramètre drawnBounds est un Rectangle qui indique la zone utile de l'image, c'est à dire la partie intérieure non vide de l'image.
    Pour les paramètres de méthode, x et y sont les coordonnées où on veut afficher, et le tableau de couleurs indique quelles couleurs seront utilisées pour la superposition du dégradé.
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    public void draw(Graphics2D g, int x, int y, Color[] c) {
        if (image == null)
          load();
        g.drawImage(image, x + drawnBounds.x, y + drawnBounds.y, null);
        PaintToolkit.drawAdditionnalGradient(g, image, c, x + drawnBounds.x, y + drawnBounds.y);
      }


    Vient ensuite le service de la classe PaintToolkit :
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
     
    // ajoute la couche colorée sur une image
      public static void drawAdditionnalGradient(Graphics2D g, BufferedImage i, Color[] c, int x, int y) {
        int w = i.getWidth();
        int h = i.getHeight();
        BufferedImage b0 = DirectBufferIO.createBuffer(w, h, Transparency.TRANSLUCENT);
        BufferedImage b1 = DirectBufferIO.createBuffer(w, h, Transparency.TRANSLUCENT);
        Graphics2D g0 = b0.createGraphics();
        Graphics2D g1 = b1.createGraphics();
     
        int alpha = c[0].getAlpha();
        if (alpha < 255)
          g0.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, (float)alpha / 255f));
        g0.drawImage(i, 0, 0, null);
        PaintToolkit.fillOpaqueGradient(g1, c, new Rectangle(0, 0, w, h));
        b1.getAlphaRaster().setRect(b0.getAlphaRaster());
        g.drawImage(b1, x, y, null);
     
        g0 = null;
        g1 = null;
        DirectBufferIO.flushBuffer(b0);
        DirectBufferIO.flushBuffer(b1);
      }
     
    // remplit un rectangle avec un tableau de dégradés rendus opaques
      public static void fillOpaqueGradient(Graphics2D g, Color[] c0, Rectangle b) {
        Color[] c = new Color[c0.length];
        for (int i = 0 ; i  < c0.length ; i++)
          c[i] = ColorToolkit.setAlpha(c0[i], 255);
        fillGradient(g, c, b);
      }
     
    // remplit un rectangle avec un tableau de dégradés
      public static void fillGradient(Graphics2D g, Color[] c, Rectangle b) {
        int n = c.length - 1;
        if (n == 0) {
          fillGradient(g, c[0], c[0], b);
          return;
        }
        int h = b.height / n;
        n--;
        Rectangle r = new Rectangle(b.x, b.y, b.width, h);
        for (int i = 0 ; i < n ; i++) {
          fillGradient(g, c[i], c[i + 1], r);
          r.y += h;
        }
        r.height = b.y + b.height - r.y;
        fillGradient(g, c[n], c[n + 1], r);
      }
     
    // remplit un rectangle avec un dégradé de c0 à c1
      private static void fillGradient(Graphics2D g, Color c0, Color c1, Rectangle r) {
        Paint p = g.getPaint();
        if (c0.getRGB() != c1.getRGB())
          g.setPaint(new GradientPaint(r.x, r.y, c0, r.x, r.y + r.height, c1));
        else
          g.setColor(c0);
        g.fillRect(r.x, r.y, r.width, r.height);
        g.setPaint(p);
      }
    __________________________________
    | +
    | Sylvain Tournois - Création logicielle
    |
    | sylv.tournois.free.fr
    |

  5. #5
    Expert éminent sénior
    Citation Envoyé par anadoncamille Voir le message
    j'ai désactivé le thread d'affichage awt, je suis en monotache sur une JFrame modifiée pour faire du plein écran
    Euh... Que veux-tu dire par là exactement ?
    Comment fait tu pour désactiver le thread d'affichage ????

    Citation Envoyé par anadoncamille Voir le message
    En plus, sur les anciennes versions de JRE ou JDK, ça fonctionne correctement, c'est dans la dernière version que le bug apparait. J'ai réinstallé une ancienne version et ça fonctionne à nouveau.
    Les bugs lié aux accès concurrents sont non seulement difficile à débugger, mais également très fluctuant. Dans certain cas cela pourrait marcher mais cela ne veut pas dire que le code est correct

    Est-ce que tu utilises bien le méthode paint()/paintComponent() d'AWT/Swing (selon le cas) ?

    a++
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  6. #6
    Membre actif
    si si si !
    je publierai un code allégé et commenté de la frame en question, mais je n'utilise pas paint mais la méthode BufferStrategy.show().

    Voici la méthode de dessin :

    Soit EAppli une interface contenant entre autres les méthodes suivantes :
    - live(); : fait un tour de calculs
    - draw(Graphics2D g, Rectangle r); : dessine dans le graphics g pour le rectangle r

    buffStrat est le BufferStrategy de la JFrame.

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
      private void liveAppli(EAppli ap) {
        ap.live();
        ap.draw((Graphics2D)buffStrat.getDrawGraphics(), drawBounds);
        if ((!buffStrat.contentsLost()) && (!buffStrat.contentsRestored()))
          buffStrat.show();
      }


    Voici maintenant l'initialisation de la frame :

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
     
      public KFrame(int width, int height, int depth, EAppli app) {
        super("");
        setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        addWindowListener(new WindowAdapter() {
          public void windowClosing(WindowEvent e) {
            exit();
          }
        });
        setUndecorated(true);
        setResizable(false);
        setFocusable(true);
        setVisible(true);
        DisplayMode displayMode = chooseDisplayMode();
        DisplayModeToolkit.setFullScreen(this, displayMode);
        createBufferStrategy(3);
        buffStrat = getBufferStrategy();
        drawBounds = getBounds();
      }


    et la méthode pour le plein écran :

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
     
      public static boolean setFullScreen(Window wi, DisplayMode dm) {
        boolean ok = graphicsDevice.isFullScreenSupported();
        if (ok)
          graphicsDevice.setFullScreenWindow(wi);
        else
          return false;
        ok = graphicsDevice.isDisplayChangeSupported();
        if (ok) {
          try {
            graphicsDevice.setDisplayMode(dm);
          }
          catch (Exception e) {
            currentDisplayMode = startingDisplayMode;
            graphicsDevice.setDisplayMode(startingDisplayMode);
            graphicsDevice.setFullScreenWindow(null);
            return false;
          }
        }
        else
          return false;
        currentDisplayMode = dm;
        return true;
      }


    Mais je ne crois pas que le bug vienne de là, seuls les personnages colorés par code sont buggés, les autres s'affichent normalement.

    Ce que j'envisage actuellement est plutôt une redéfinition du paramètre SRC_OVER qui effectue la combinaison des images.
    __________________________________
    | +
    | Sylvain Tournois - Création logicielle
    |
    | sylv.tournois.free.fr
    |

  7. #7
    Expert éminent sénior
    Disons que le problème vient du fait que l'affichage DOIT se faire via le thread de l'EDT, et via la méthode paint()/paintComponent().


    Si tu ne respectes pas cela tu peux t'attendre à des bugs aléatoire selon la JVM...

    a++
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  8. #8
    Membre actif
    un autre chemin
    Je viens de poster une classe complète et fonctionnelle de JFrame plein écran qui n'utilise pas paint(), l'affichage se fait manuellement.

    Voici le lien vers le post :JFrame plein écran
    __________________________________
    | +
    | Sylvain Tournois - Création logicielle
    |
    | sylv.tournois.free.fr
    |

  9. #9
    Expert éminent sénior
    Comme je l'ai dit, cela n'est pas correct : le thread graphique est automatiquement lancé lorsque tu affiches une fenêtre, et gère l'affichage et les événements...

    De plus ta boucle while(true) fsf.turn(); me bloque le processus à 100%


    Ce n'est pas une manière de programmer en Swing, et les problèmes que tu rencontres ne m'étonnes pas...

    a++
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  10. #10
    Expert éminent sénior
    Pour moi cela ressemble pas pal à un problème introduit par le nouveau pipeline Direct3D introduit dans l'update 10 de java6.

    cf

    Citation Envoyé par java 6 updates 10 release notes

    Requirements


    • DirectX 9.0c runtime or later (refer to http://www.microsoft.com/directx). The dxdiag tool from Microsoft specifies the version of DirectX that is installed on your computer (see also http://support.microsoft.com/kb/190900).
    • Latest drivers are very much encouraged
    • Required hardware capabilities must be present:
      • hardware transform and lighting (HW TnL)
      • the device must support Pixel Shaders 2.0 model
      • Some more advanced optimizations are only available on devices supporting Pixel Shader 3.0 model.


    Limitations


    • Only devices produced by Nvidia and ATI are currently supported due to performance and driver quality issues. Other manufacturers (such as Intel) may be supported in a future release.
    • Some operations not directly supported by Direct3D API may perform slower than with previous releases (such as XOR paint mode)
    • The pipeline may be disabled on certain combinations of hardware and drivers where there are known bugs in the drivers. Again, make sure you have the latest drivers.
    • The pipeline is only enabled on Microsoft's client operating systems (Windows XP, Windows Vista) and not on the Windows Server line (Windows 2000, 2003, 2008) due to poor driver support and differing server requirements.
    • Due to a bug in the Microsoft Display Window Manager (Aero), on Windows Vista with Aero interface enabled, hardware accelerated rendering is disabled for applets embedded in a browser. Standalone applet windows remain hardware accelerated. For more information, see 6670586 .

    Troubleshooting


    • To disable the Direct3D Pipeline, pass the following property to the Java VM: -Dsun.java2d.d3d=false
      Alternatively, set the J2D_D3D environment variable to 'false' prior to starting your application (or set it globally).
    • To get diagnostic information about the pipeline set the following environment variable prior to starting any GUI application from a command line console: J2D_TRACE_LEVEL=4. The tracing output will be printed into the console. Please provide this output when filing a bug or asking a question on the forums.
    • Some operations not directly supported by Direct3D API may perform slower than with previous releases (such as XOR paint mode or rendering on non-managed images). See 6635462 and 6652116
    • For more information about troubleshooting issues with Java2D consult Troubleshooting Java 2D .


    Un peu plus d'infos pour rechercher la source de l'erreur:


    Starting with the Java SE 6 release, the Direct3D pipeline uses the Direct3D API for rendering. This pipeline is enabled in full-screen mode by default, if the drivers support the required features and the level of rendering quality.
    With both the Java SE 5 and 6 releases, it is possible to enable the Direct3D pipeline or to force its use, as described in the subsections below.
    Consider enabling the Direct3D pipeline for your application if it makes heavy use of rendering operations such as alpha compositing, antialiasing, and transforms.
    However, use caution when deciding to enable this pipeline in your application. For example, some built-in video chipsets (which are used in most notebooks) do not perform well using Direct3D, even if they satisfy the quality requirements for Java 2D pipelines.
    3.1.4.1 Disabling the Direct3D Pipeline

    Some older video boards/drivers combinations are known to cause issues (both rendering and performance) with the Direct3D pipeline. To disable the pipeline in such cases, with both the Java SE 5 and 6 releases, pass the parameter -Dsun.java2d.d3d=false to the Java VM, or set the J2D_D3D environment variable to false.
    3.1.4.2 Forcing the Use of the Direct3D Pipeline

    With both the Java SE 5 and 6 releases, to enable the Direct3D pipeline in both windowed and full-screen mode, use the parameter -Dsun.java2d.d3d=true, or set the J2D_D3D environment variable to true. Note that the pipeline is enabled only if the drivers support minimum required features.
    3.1.4.3 Diagnosing Rendering Problems with Direct3D Pipeline

    With the Java SE 6 release, some rendering issues (like missing pixels, garbled rendering) can be diagnosed by forcing different Direct3D rasterizers. Set the J2D_D3D_RASTERIZER environment variable to one of the following: ref, rgb, hal, or tnl.
    Refer to Direct3D documentation for a description of these rasterizers. By default the best rasterizer is chosen based on its advertised capabilities. In particular, the ref rasterizer forces the use of the reference Direct3D rasterizer from Microsoft. If a rendering problem is not reproducible with this rasterizer, then it is very likely to be a video driver bug.
    The rgb rasterizer is available only if the Direct3D SDK is installed. This SDK can be obtained from Microsoft Game Technologies Center.
    For performance or quality problems with text rendering with the Direct3D pipeline, you can force the use of ARGB texture instead of the default Alpha texture for the Direct3D pipeline's glyph cache. To do this, set the J2D_D3D_NOALPHATEXTURE environment variable to true.

    Essaie également de voir ce que donne le pipeline OpenGL pour toi en passant l'option -Dsun.java2d.opengl=true dans la commande de lancement de ton appli.
    Hey, this is mine. That's mine. All this is mine. I'm claiming all this as mine. Except that bit. I don't want that bit. But all the rest of this is mine. Hey, this has been a really good day. I've eaten five times, I've slept six times, and I've made a lot of things mine. Tomorrow, I'm gonna see if I can't have sex with something.

  11. #11
    Expert éminent sénior
    Citation Envoyé par adiGuba Voir le message


    Ce n'est pas une manière de programmer en Swing, et les problèmes que tu rencontres ne m'étonnes pas...

    a++
    +1, et si tu veux facilement constater que c'est problèmatique essaie de placer un lookandfeel exigeant qui lance des exception dès que tu fait ce genre de truc interdit. Tu va me dire "je compte pas utiliser ce genre l&f donc pas de problème". Faux, car ce qu'exige ce l&f, le l&f de base l'exige aussi, la différence c'est qu'il ne force rien, menant occasionellement à des bugs. C'est peut etre un problème de pipleine D3D (for possible même) mais perd pas de vue que si tu ne travaille pas tes Graphics écran dans l'EDT t'as absolument aucune garantie que l'EDT ne va pas y changer des valeur en meme temps (comme les masque ou les règles de superposition)!
    David Delbecq Java developer chez HMS Industrial Networks AB. &#12288;&#12288;&#12288;LinkedIn | Google+

  12. #12
    Membre actif
    ce n'est pas faux, juste inhabituel
    loin de moi l'idée de proposer un nouveau standard de programmation, je vous accorde volontiers que ma façon de programmer est inhabituelle.

    Par contre mes méthodes sont fonctionnelles, et ma spécification de projet est : monotache, prend toutes les ressources disponibles, plein écran. Dans le même style, j'utilise le Garbage collector en appel volontaire quand j'ai besoin de mémoire (ce qui est aussi inhabituel). Mais le jeu vidéo présente des contraintes que les applis standards n'ont pas.

    Voilà les raisons de ma façon de faire. Je vous invite vivement à regarder mon projet pour vous faire une meilleure idée. Dans AnAcondA les fenêtres et look&feel ne me sont pas utiles et chercher à les avoir m'empêcherait d'autres options que j'ai développées pour ce projet. Par contre j'utilise volontiers les threads d'affichage awt et swing pour d'autres applis plus standard. Je retiens l'idée des paramètres D3D, c'est ce que je m'en vais tester.

    Au fait pour la fenêtre, elle n'est pas bloquante, c'est Alt-F4 pour quitter.
    __________________________________
    | +
    | Sylvain Tournois - Création logicielle
    |
    | sylv.tournois.free.fr
    |

  13. #13
    Expert éminent sénior
    @Adiguba & Tchize_:

    Euh en fait le truc ici c'est qu'à aucun moment anadoncamille ne bypasse l'EDT en lui même, tous les appels réalisés sont faits depuis l'EDT vu qu'à aucun moment un autre thread n'est créé.
    C'est juste le mécanisme de paint qui est bypassé, rien de plus. Et c'est tout à fait normal dans le cadre d'utilisation d'une BufferStrategy en fullscreen
    cf http://java.sun.com/docs/books/tutorial/extra/fullscreen/bufferstrategy.html et plus généralement http://java.sun.com/docs/books/tutor...een/index.html

    @anadoncamille: à aucun moment tu ne désactives l'EDT, je ne vois pas en quoi bypasser le paint le ferait. Ta buffer stratégie fait ses appels dans l'edt donc y est soumise. La seule chose que tu fais différemment est de gérer le moment ou le rendering est effectué, point barre. Le thread graphique d'AWT tourne toujours en background ne serait-ce que pour traiter tout ce qui est inputs.

    On est en plein méli mélo d'incompréhensions et imprécisions là.
    Hey, this is mine. That's mine. All this is mine. I'm claiming all this as mine. Except that bit. I don't want that bit. But all the rest of this is mine. Hey, this has been a really good day. I've eaten five times, I've slept six times, and I've made a lot of things mine. Tomorrow, I'm gonna see if I can't have sex with something.

  14. #14
    Rédacteur/Modérateur

    Oui oui il y a des moment ou il faut redefinir son propre algo de peinture ou son propre repaint manager comme par exemple lorsqu'on est en plein ecran ou faire certains effets comme des reflets (voir le bouquin de Gfx).
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

  15. #15
    Expert éminent sénior
    je crois que c'est le
    j'ai désactivé le thread d'affichage awt
    qui a porté à confusion, effectivement, après vérification, je ne vois pas de code manipulant les composant graphiques en dehors de l'EDT, donc pas de soucis par là Désolé
    David Delbecq Java developer chez HMS Industrial Networks AB. &#12288;&#12288;&#12288;LinkedIn | Google+

  16. #16
    Expert éminent sénior
    Citation Envoyé par anadoncamille Voir le message
    Dans le même style, j'utilise le Garbage collector en appel volontaire quand j'ai besoin de mémoire (ce qui est aussi inhabituel).
    Le problème c'est que cela génère des full-GC même s'il n'y a rien à libérer (Un exemple marquant : Difference de performances Unix/Windows d'un programme?).
    Et dans tous les cas le GC fera un full-GC si c'est nécessaire...

    Citation Envoyé par sinok Voir le message
    @Adiguba & Tchize_:

    Euh en fait le truc ici c'est qu'à aucun moment anadoncamille ne bypasse l'EDT en lui même, tous les appels réalisés sont faits depuis l'EDT vu qu'à aucun moment un autre thread n'est créé.
    Les appels sont quand même fait depuis le thread "main", et logiquement le thread de l'EDT est implicitement créé lors de l'affichage de la fenêtre...


    Mais bon tout cela m'échappe un peu

    a++
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  17. #17
    Expert éminent sénior
    Citation Envoyé par adiGuba Voir le message


    Mais bon tout cela m'échappe un peu

    a++
    pour ce que j'ai compris, il travaille sur dess Graphics qui sont explicitement destiné à du travail en dehors de l'edt, graphics que l'on remballe ensuite à l'EDT avec un show (j'ai bon, dites j'ai bon hein? )
    David Delbecq Java developer chez HMS Industrial Networks AB. &#12288;&#12288;&#12288;LinkedIn | Google+

  18. #18
    Membre actif
    ça marche !
    Salut,

    ça y est, ça marche, j'ai ajouté -Dsun.java2d.d3d=false à la ligne de commande et je retrouve les couleurs normales.

    Effectivement, je me suis emballé en vous disant que je "désactive le thread awt". Je l'utilise pour recevoir les input et je ne le désactive pas du tout. Par contre la méthode paint() est vide et inutilisée.

    pour ce que j'ai compris, il travaille sur dess Graphics qui sont explicitement destiné à du travail en dehors de l'edt, graphics que l'on remballe ensuite à l'EDT avec un show
    Oui c'est tout à fait ça !

    Merci à vous tous pour votre aide.

    a+

    __________________________________
    | +
    | Sylvain Tournois - Création logicielle
    |
    | sylv.tournois.free.fr
    |

  19. #19
    Expert éminent sénior
    Citation Envoyé par anadoncamille Voir le message
    Salut,

    ça y est, ça marche, j'ai ajouté -Dsun.java2d.d3d=false à la ligne de commande et je retrouve les couleurs normales.

    Eventuellement il serait pas mal que tu fasses remonter un bug report à sun vu que le bug est dû à une fonctionnalité relativement récente.

    A moins que ton bug ne soit en relation avec le suivant: http://bugs.sun.com/view_bug.do?bug_id=6758179, dans ce cas un fix sera fourni pour l'update 12 de java 6. Tu peux d'ors et déjà récupérer un build de cette release à l'adresse suivante: https://jdk6.dev.java.net/6uNea.html
    Hey, this is mine. That's mine. All this is mine. I'm claiming all this as mine. Except that bit. I don't want that bit. But all the rest of this is mine. Hey, this has been a really good day. I've eaten five times, I've slept six times, and I've made a lot of things mine. Tomorrow, I'm gonna see if I can't have sex with something.

  20. #20
    Expert éminent sénior
    Citation Envoyé par tchize_ Voir le message
    pour ce que j'ai compris, il travaille sur dess Graphics qui sont explicitement destiné à du travail en dehors de l'edt, graphics que l'on remballe ensuite à l'EDT avec un show (j'ai bon, dites j'ai bon hein? )
    Ok je comprend mieux tout cela



    Une autre piste pourrait consister à utiliser un Frame ou Window (AWT donc) plutôt qu'une JFrame. Avec Java 6 les composants Swing dispose d'un double buffering qui pourrait peut-être te gêner.

    De toute manière cela ne devrait pas te changer grand chose puisque tu n'utilises pas le système de dessin standard...


    a++
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

###raw>template_hook.ano_emploi###