Image.Smooth() broken?

[bastien]

Image.SetSmooth() doesn't seem to do anything in my programs (it doesn't crash though). I'm using PySFML 1.6 from the Arch Linux packages.

In February Tank talked about this bug here:

Also sf::Image::SetSmooth() and sf::Image::Copy() are not working. This will be fixed with the next revision.

I had a quick look at SFML's code on SourceForge, and there's indeed a revision saying that SetSmooth() has been fixed.

Can anyone test SetSmooth() with 1.6 and tell me if it works? In that case I'll try to see if something is wrong with the Arch Linux package.

[Svenstaro]

Smooth is broken in 1.6 release. I did not backport the patches. If you want it working, use sfml from svn. I did not patch the Arch packages either so it will be broken there as well.

[bastien]

OK, it works with trunk. Why not make a new PySFML release with the fix? It's not very user-friendly to have to install from SVN for such an important and old bugs.

[Svenstaro]

PySFML needs a lot of work to make it maintainable again. It should be redone using SWIG instead of direct Python ctypes. This revisit is planned for SFML 2 and at least I am not going to rebuild SFML 1 from svn to fix this bug.

You should consider helping out with SWIG if you want a working PySFML 2.

[bastien]

PySFML needs a lot of work to make it maintainable again. It should be redone using SWIG instead of direct Python ctypes.

I thought PySFML was written by hand with the C extension API?

This revisit is planned for SFML 2 and at least I am not going to rebuild SFML 1 from svn to fix this bug.

If I understand correctly you don't have to rebuild SFML, I just downloaded the python directory from the trunk and built the extension module.
Making this module available instead of the broken one would allow people to use SetSmooth().
If for some reason that's not possible in my opinion we should tell people that the current version is broken and they may need to build it from SVN.

You should consider helping out with SWIG if you want a working PySFML 2.

Does SWIG automatically converts C++ names to Python names, creates properties instead of Get/Set and stuff like that?
Personally I was considering using Cython for creating a more pythonic binding, but I haven't tried it yet.

[Svenstaro]

A proper SWIG binding would allow many script bindings to be created (Perl, Python, Lua and what-not). It does a lot of magic and is very fast. We should try that in favor of anything else.

Let's not bother with SFML 1 anymore. SFML 1 has critical network bugs as well and we should not promote it any further. If you want to help out, play around with SWIG. Any help would be greatly appreciated.

[Laurent]

I'm not a big fan of SWIG -- at least in the context of SFML bindings. There are so many things that need to be "translated" to fit the conventions of the target language, I don't think that an automatic binder can do it properly. Moreover, there are internal details that may have to be added manually (for example in the .Net binding I have to take care of the OpenGL context because of threading issues with the GC).

Have you already played with SWIG to see what the resulting API looks like?

[Svenstaro]

I have only played with it a little in my own small libs. It looked good there but it also is a very simple lib. I will test around with SWIG and SFML after my exams.

[Kaoron]

Hi guys. Didn't Tank project to port pysfml to boost.python ? Have news from him ?

Not a big fan of SWIG either, I had to deal with a poorly ported lib some time ago, the binding was buggy, and fixing the swig stuff manually was just awful.

Edit : you could also consider Cython/Pyrex which looks more pythonic and seems to have better perfs than boost/SWIG, however it looks more friendly with C than C++

Oh, and this comparison on wrapping methods is interesting.

[Tank]

Yep, I did tests with Boost.Python and also SWIG. For both I created wrappers for important classes like sf::RenderWindow, sf::Sprite and sf::Image to do some benchmarking. As for Boost.Python I released the results in this forum and it turned out that Boost.Python is way too slow for SFML, since the calls take more time than with other solutions.

With SWIG I was able to compile and link the Python extension library, however it has always segfaulted because of some threading issue (AFAIR it had its origin somewhere in sf::Context).

As far as I know, SWIG is indeed flexible enough to give you the power to modify the binding for specific target languages. But I'm not really sure about this and to be honest I'm not a big fan of the SWIG approach anymore since it has a kinda complicated way of doing things. There're still some wrappers left on my list that I wanted to take a look at.

However I fully agree with svenstaro, the "raw" Python C API binding is absolute unmaintainable and error-prone. I hope there'll be another nice way to get a clean Python binding in a more elegant way.

Edit: Pyrex/Cython are no options here. Both are new Python-like languages that generate C or C++ code that's being compiled to a Python extension. It's not really meant to wrap existing code, but write new.

[Tank]

I just found out about a code generator called "pybindgen". It's basically a Python module that generates C++ code for the Python C API. To wrap, you simply use that Python module and define classes, methods etc. there. Completely neat in my eyes!

Up to now I've wrapped sf::Vector2 and sf::Window (plus related ones like sf::ContextSettings etc.). The window shows up properly and I think we've got definitely an interesting option to create further PySFML releases. Of course the extension module still needs to be benchmarked.