I'm running on Windows 7.
I tried both 32 and 64 bit now, and in a simple C++ program, it works as you described, textures are fine even if loaded before a window or context is created.
sf::Texture *texture = new sf::Texture();
texture->loadFromFile("test.png");
sf::RenderWindow *window =
new sf::RenderWindow(sf::VideoMode(640, 480), "Context test");
sf::Sprite *sprite = new sf::Sprite(*texture);
while(window->isOpen()) {
window->clear();
window->draw(*sprite);
window->display();
sf::Event e;
while(window->pollEvent(e)) {
if(e.type == sf::Event::Closed) {
window->close();
}
}
}
delete sprite;
delete window;
delete texture;
(Just in case you wonder why I use pointers - I wanted to resemble as good as possible what happens when using the Java binding.)
The same program using the Java binding results in a white box being painted. The dimensions of the texture are correct (same as the source image), but the content is plain white. As soon as I create a sf::Context instance before creating (loading) the texture, it works just like in the program above.
So this is definitely a problem with my binding, but it is still awkward. The native code executed should be practically the same that I posted above.
I wouldn't know of any thread shenanigans going on in the background in Java, but even if so, according to you, that should not be a problem.
Are you really sure that there's no hidden thread spawned internally?
Everything is done in the main thread. Calling native code does not change threads.
What you can try now, is to call glFlush() (include and link OpenGL) right after calling texture.loadFromFile in your binding.
Tried that now, no change. :(
JNIEXPORT jboolean JNICALL Java_org_jsfml_graphics_Texture_nativeLoadFromMemory
(JNIEnv *env, jobject obj, jbyteArray arr, jobject area) {
std::size_t n = (std::size_t)env->GetArrayLength(arr);
jbyte* mem = env->GetByteArrayElements(arr, 0);
jboolean result = THIS(sf::Texture)->loadFromMemory(mem, n, JSFML::Intercom::decodeIntRect(env, area));
glFlush();
env->ReleaseByteArrayElements(arr, mem, JNI_ABORT);
return result;
}
I should note that I use loadFromMemory because I handle files on a Java-level, that allows a more detailled exception handling and only needs one "load" implementation that I can use for Java input streams as well. I don't think that should make any difference.