Enabling/Disabling config file

[golgoth]

Greetings,

Is there any chance of having a Configuration file to enable/disable features inside SFML librairies?

On my side, I only use a Window, Inputs, a clock and Threads… so there is a lot of things I’m not using but force to link against. Would be nice to custom fit and build only features we need.

Excluding jpeg lib and freetype lib would be really appreciated and/or providing x64 version as well.

[Laurent]

Is there any chance of having a Configuration file to enable/disable features inside SFML librairies?

No. If you need a minimal build of SFML, modify it and compile your own version. But honestly I don't see why you would need that.

there is a lot of things I’m not using but force to link against

Which libraries are you talking about exactly? freetype and libjpeg? What's the problem with these libraries? On Windows they are statically linked, and on Linux everybody has them. And from what you said, you don't need the graphics module at all, do you?

[Hiura]

What is your objective with that ? Performance ? You wouldn't notice any gain at runtime, it's so (soooooooo) small.

EDIT : he's fast, too fast for me ^^

[Groogy]

There won't be any gain in performance by removing, only a smaller executable which might be the goal. The only "overhead" which is microscopic would be when the executable is loaded into memory.

But anyway you don't need to link against every SFML library, only the ones you use. So for instance from what you've told us your only using the Window and System libraries. So those are the only ones you need to link against. You don't need to link against jpeg lib och freetype lib since the SFML libraries already does that for you. If your trying to get the last squeeze of performance then by removing freetype and jpeg will give you none. If you are like I said trying to get a smaller executable then having the SFML libraries being dynamically linked will give you as small executable as you can possibly get trough any tweaking with SFML.

[golgoth]

Which libraries are you talking about exactly? freetype and libjpeg? What's the problem with these libraries? On Windows they are statically linked, and on Linux everybody has them. And from what you said, you don't need the graphics module at all, do you?

Well, linking SFML x64 on windows 7 and vs 2010 return jpg_* unresolved. It’s quite annoying when it’s something you don’t need.

Yes, I’m force to link graphics.lib because I use RenderWindow->Draw to render video playback in a window. Then again, the Draw function requires a whole lib. In my sense, drawing mechanics should be inherent from Window. Let developers handle their rendering technics if they want to and put every drawable in graphics.lib.

My point is to rethink how SFML is segmented to allow a minimum core where performance is a must and there is no need for non-highly-optimized rendering stuff. Having built customization under the hood to make sure libraries could be include/exclude regardless of whether there is a performance gain or not. I think it’s a basic practice to enable/disable external libs and keep the core to a minimum if we want to.

Regards,

[Laurent]

Well, linking SFML x64 on windows 7 and vs 2010 return jpg_* unresolved. It’s quite annoying when it’s something you don’t need.

I can't help much on 64 bits issues, I have no such system to test. But obviously the solution to this problem is to make it work, not to get rid of libjpeg (most x64 users will need the full graphics package).
Maybe you can help me fix this bug.

Yes, I’m force to link graphics.lib because I use RenderWindow->Draw to render video playback in a window. Then again, the Draw function requires a whole lib. In my sense, drawing mechanics should be inherent from Window. Let developers handle their rendering technics if they want to and put every drawable in graphics.lib.

That's exactly what I do. sfml-window provides a raw OpenGL context, nothing fancy on top of it. The rendering stuff is entirely left to the user. Using sf::RenderWindow means that you use the advanced features of the 2D SFML API (not just a window); if you want something minimal then you already have too much here.

My point is to rethink how SFML is segmented to allow a minimum core where performance is a must and there is no need for non-highly-optimized rendering stuff. Having built customization under the hood to make sure libraries could be include/exclude regardless of whether there is a performance gain or not.

There is no performance gain. Getting rid of external dependencies will only remove features from SFML. So what's the point?

[golgoth]

most x64 users will need the full graphics package

Hi there,

My guess is as we speak, projects not bothering with high performance might not be compiled in x64 anyways. So I’m expecting a totally different breed of developers being concerned about this topic… or not? But yes indeed, if I can help, I’ll certainly will. And so far, SFML audio is not compiling and jpeglib returns unresolved errors while linking against my project.

Personally, I can’t wait people letting go of x86 and kiss it goodbye…

That's exactly what I do. sfml-window provides a raw OpenGL context, nothing fancy on top of it. The rendering stuff is entirely left to the user. Using sf::RenderWindow means that you use the advanced features of the 2D SFML API (not just a window); if you want something minimal then you already have too much here.

No need for fancy stuff, only a default Window::pixelbuffer (sf::Image substitue) we can draw on will do.
While at it, other pixel formats would be great, rgb24 (without alpha) at least.

There is no performance gain. Getting rid of external dependencies will only remove features from SFML. So what's the point?

I guess the point is a question of preferences. What’s the point of carrying libraries you don’t need?

[Groogy]

If you really want it minimalistic, use only the sf::Window class and have OpenGL render the graphics for you. That's as minimalistic you can be.

If I remember correctly, sf::RenderWindow uses OpenGL in the background but hides it from you?

[golgoth]

If I remember correctly, sf::RenderWindow uses OpenGL in the background but hides it from you?

That is a really good question, unless SFML is rendering on a quad that covers the entire screen I’m not sure how it does render windows, directly into a FBO?

However, it would be nice to access the frame buffer without the need of the graphics.lib, Draw, Clear and SwapBuffer functions would be a definite plus!

[golgoth]

EDIT: The reason I’m asking this is because I’m trying to render 1080p HD video directly in a Window. Syncing audio and video is a fairly complex process and so far, 720p is going very well but the pipeline is stalling with 1080p… I’m currently using sf::Image:UpdatePixels to update each frame and I’m looking at a more direct way to access the frame buffer. If that is possible.

[Laurent]

However, it would be nice to access the frame buffer without the need of the graphics.lib, Draw, Clear and SwapBuffer functions would be a definite plus!

- Clear is glClear.
- SwapBuffer is Window::Display()
- Draw is... whatever you want with OpenGL

EDIT: The reason I’m asking this is because I’m trying to render 1080p HD video directly in a Window. Syncing audio and video is a fairly complex process and so far, 720p is going very well but the pipeline is stalling with 1080p… I’m currently using sf::Image:UpdatePixels to update each frame and I’m looking at a more direct way to access the frame buffer. If that is possible.

On modern platforms (I mean since GPUs exist), accessing directly the framebuffer is not possible anymore. You have to use the path that graphics drivers define for you, which consists of uploading the data to a texture and then rendering this texture on a fullscreen quad.
That's basically what sf::Image::UpdatePixels do, and the only faster solution is maybe to use OpenGL PBOs (pixel buffer objects).

Of course I assume that you're using sf::Image and sf::Sprite in the most efficient way. And that you're not doing silly things such as testing in debug mode

The other video project from Ceylo, that you can see on the wiki forum, is pretty good at playing HD videos, it has no performances problem so far.

[nfries88]

I’m currently using sf::Image:UpdatePixels to update each frame and I’m looking at a more direct way to access the frame buffer. If that is possible.

As Laurent said, that is the most direct way possible.

Are you using a single instance of sf::Image throughout the entire video? This could make it slower because it needs to continually upload each new frame to the GPU before it can be drawn. Instead, use a separate instance of sf::Image for each frame.

[golgoth]

Are you using a single instance of sf::Image throughout the entire video? This could make it slower because it needs to continually upload each new frame to the GPU before it can be drawn. Instead, use a separate instance of sf::Image for each frame.

Are you suggesting not to use sf:Image as a member variable?

here is what I do: m_SFML_Image and m_SFML_Sprite are class member variables.

Code: [Select]

/// Init
m_SFML_Image.Create(m_Size.x, m_Size.y, sf::Color(255, 0, 0, 255));
m_SFML_Sprite = AX6_New sf::Sprite(m_SFML_Image);

// Update
if (m_Movie->IsUpdated())
{
m_SFML_Image.UpdatePixels(m_Movie->GetPixelData());
}
m_SFML_Window->Draw(*m_SFML_Sprite);
m_SFML_Window->Display(); /// Swap Buffer.

The other video project from Ceylo, that you can see on the wiki forum, is pretty good at playing HD videos, it has no performances problem so far.

Is this the project you are talking about?

http://www.sfml-dev.org/wiki/fr/tutoriels/integrervideo

This is a good start but it is nowhere near being a video player.

That's basically what sf::Image::UpdatePixels do, and the only faster solution is maybe to use OpenGL PBOs (pixel buffer objects).

Interesting, I’m looking into PBOs which are different form FBOs…

Thx for the inputs,

[Ceylo]

The other video project from Ceylo, that you can see on the wiki forum, is pretty good at playing HD videos, it has no performances problem so far.

Note that I did no testing with 1080p movies, as it doesn't even fit in my screen :mrgreen: . But indeed, with 720p it uses about 30-35% CPU on Mac OS X. But it actually does not seem to be exactly the same on Windows because of a missing hardware acceleration support for converting images from YUV to RGBA.

@nfries88: I don't really understand your explanation... actually, as the image changes every frame, you'll always need to send the new data to the GPU. But well... with a definition of 1280x800 and 30 FPS there are only 120 MB of data sent each second, which is really small compared to the maximum transfer rate (several GB/s).

[Ceylo]

Is this the project you are talking about?

http://www.sfml-dev.org/wiki/fr/tutoriels/integrervideo

This is a good start but it is nowhere near being a video player.

No. THIS is what Laurent was talking about (and here is the English topic on the forum).