Try 3.1.0-beta6 before I announce it

Thus spake “Brent Easton”:

This is kind of what I was expecting—the unaffected one is ARGB, while
the problem one is RGB. They must not take the same rendering path on
your system…

Do you think you could try to work up a minimal example which exhibits the
problem, something like a JPanel in a JFrame? That might be easier for you
than me, since you’d be able to see immediately if you have it.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

OK, Will have a play with it.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

I’ve had trouble reproducing this in a small example outside of Vassal.

I did a bit of debugging and the problem seems to be tied up with the conversion to ‘Compatible’ images and the use of the swingx GraphicsUtilities class.

I was poking around and found that forcing RGB images to be AGRB in ImageUtils.coerceToIntType() (See swampwallaby-work4@4642) fixes bug 2358673 for me.

However, I have found a related bug - I hadn’t noticed it before, bit the the Drag cursor images are displayed strangely in a similiar, but not quite the same fashion.

In PieceMover.DragHandler.makeDragCursor(), changing

final BufferedImage cursorImage = ImageUtils.createCompatibleTranslucentImage(w, h);

to

final BufferedImage cursorImage = new BufferedImage(w, h, BufferedImage.TYPE_4BYTE_ABGR );

fixes this problem.

These two changes fix all of the problems I have found, but I am not sure of the wider implications?

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Er? That’s weird. What happens if you make it BufferedImage.TYPE_INT_ARGB
instead?

If we can’t detect this programmatically, then I think I think we should
have a switch for this in the preferences. Rendering should be a bit faster
when we don’t forcing all images to have an alpha channel, so it would be
nice if people not afflicted by this problem could take advantage of that.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Yes, that works also.

Yes, I agree on the preference. Since we have determined that it is a bug in the D3D pipeline processing when combined with nVidia drivers, I think the preference should be enabling/disabling the use of the D3D pipeline using the -Dsun.java2d.d3d=false switch when starting the Player or Editor, rather than changing code in Vassal itself. There may well be other bugs/issues that we are not aware of yet.

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

I looked at adding this preference, but logically it is a Global Preference and logically, Global preferences should be accessible from the Module Manager.

It is quite easy to add an Edit Preferences option to the MM and have it edit the Global preferences, but these prefs are also accessible from a concurrently running Player or Editor. If you change a Global pref in the Player/Editor, it is overwritten when you go back to the Manager and quit to finish your Vassal session.

Not sure of the best way to tackle this?

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)