Messages

1

Graphics / Re: VertexArray::draw performance

« on: May 22, 2018, 12:44:15 am »

It's a curve* densely packed in a square 600x600 with the top-left corner at (0, 0). When rendered with the default view it simply fills entire window with it, but the point is that you can zoom in to see how exactly it behaves in a given place.

I obviously can't pre-render it for reasons that you described. Oh, and I tested it, works fine with sf::VertexBuffer. It's not that much better, but enough.

*Hilbert's curve to be precise. I'm testing how well it maps pairs (x, y) to a single real number and parametric equations describing its shape are surprisingly hard to grasp and even harder to use when you want to check some kinds of properties. A graph like this one helps a lot when you're analyzing this kind of stuff.

//edit: And the GPU… well, it's kind of embarrassing to say this, but I'd feel defeated if I switched the dedicated NVidia card just because Intel couldn't do the job. 

//edit2: And yeah, 4.2 billion seems like a lot now, looks like I'm bad at copying stuff into my calculator. Turns out to be about 67 million. 

2

Graphics / Re: VertexArray::draw performance

« on: May 21, 2018, 09:33:43 pm »

Okay, problem solved, hopefully.

I completely overlooked the existence of sf::VertexBuffer, which seems to be a relatively recent addition to SFML and do exactly what I want. While I don't know if it will indeed solve my problem, the premise of my question has become irrelevant. I'll rewrite my code and check its performance then.

3

Graphics / VertexArray::draw performance

« on: May 21, 2018, 09:22:31 pm »

Hi,
Before explaining the actual issue I'd like to point out that I'm actually using D and dsfml instead of raw C++/SFML, but because dsfml is basically a 1:1 wrapper of SFML, I assume the problem that I face to actually emerge from SFML.

I'm drawing a VertexArray with 4.2 billion vertices and it takes… well, a lot of time. Sadly I can't just render it to a RenderTexture once and then draw the result on screen as constant zooming in and out forces me to actually re-render the array.

I did some profiling and found out that the function that takes the most of CPU time is __memcpy_avx_unaligned_erms and basically all of the time it takes is when it's called by copy_array_to_vbo_array.isra.0 from i965_dri.so shared object (.dll but on Linux). I took a quick look at SFML source and saw that it copies the array to GPU on every single drawcall, even if the contents of VertexArray haven't been modified, which is understandable as there may be references to VertexArray's elements that it has no knowledge of, so it has to assume that they have indeed changed to always produce correct results.

Is there some known way to address this issue and keep vertices on GPU that doesn't involve messing with OpenGL? Never bothered to learn it, sadly. If there isn't, what do you think about adding some function like VertexArray::prepare_draw(RenderWindow&, RenderStates) that would copy all the needed data to GPU and prepare a reusable drawable object that wouldn't need to copy anything around?

Thanks for your time,
Kamil

4

Feature requests / Re: Generalize and move ImageLoader outside of the priv namespace

« on: November 04, 2017, 03:57:46 pm »

If you really need fast loading, one extra allocation and copy is already too much. But of course you're the only one who knows what's acceptable and what's not

I want relatively fast loading, it's important, but I won't waste too much time on that as I can do more important things.

Flexible but in my opinion or poor choice for good performances. It will resize the container one by one element (even if std::vector for example internally uses exponential growth, that's still log(n) allocations) and copy the pixels one by one too, which is easily outperformed by a single allocation + memcpy.

Didn't SFML already use push_back to allocate memory internally? I thought that it did, but if it's not the case then it would be huge regression, it deserves some additional thought, apparently.

But in the end, with stb_image you'd have your code working instead of arguing here I still think that SFML is more limiting that helping in this specific context.

Others may benefit from this change as well, am I a martyr now?

I don't get it. You request a lower-level function that just loads an image into some sort of pixel container, without extra allocations and copies. SFML doesn't provide that, but this is exactly what stb_image does with a single and easy to use function (see stbi_load). If it was me, I would definitely use the latter.

Well, I'll probably go for it now. It doesn't change the fact that SFML has a relatively useful feature and hides it in priv namespace. Are you hiding some bad code there and want to keep it hidden, Laurent? 

5

Feature requests / Re: Generalize and move ImageLoader outside of the priv namespace

« on: November 04, 2017, 02:53:29 pm »

Yes, we can certainly do something about ImageLoader. But keep in mind that it will still be inefficient: internally, stb_image returns its own allocated buffer, so you will never be able to directly load the pixels into your own external buffer anyway, there will still be an extra (useless) allocation & copy.

1 copy is a lot better than two of them.

How can you pre-allocate the buffer to the correct size if you don't know the width and height of the image?

Right, stb_image obtains the size of an image and allocates the memory in the same function. Maybe something more flexible like std::back_insert_iterator? It would work with all containers from STL and a lot from other libraries. It however requires some templates, so loadFromFile/Stream/Memory would have to be moved to the ImageLoader.hpp file.

Then SFML is definitely NOT the right library. As you said, sf::Image is just a basic and limited container for pixels with a few loading functions. SFML was never designed for advanced image manipulation.

Exactly, TBH I couldn't find any decent library providing an immutable image class. That's why I wrote it myself.

If you plan to make your own implementation of SIMD etc. then use stb_image, if you look at ImageLoader implementation you can see that SFML does almost nothing on top of it.

SFML wraps C into nice C++ API making my code easier to maintain, provides sf::Vector2<T> and sf::Color minimizing the boilerplate code that I'd have to write, and is a popular library with a big community that can provide me some support when needed. That's why it's a better choice instead of the raw stb_image.

Otherwise I'm sure you can find other, dedicated libraries that will better suit your needs.

I think I covered this above.

6

Feature requests / Re: Generalize and move ImageLoader outside of the priv namespace

« on: November 04, 2017, 09:17:58 am »

Why is sf::Image slow?

• It's mutable and thus requires synchronization between threads if one can't enforce not using non–const methods
• Doesn't use SIMD (and I managed to make some functions 14x faster with Boost.SIMD)

Neither of them can be easily fixed in SFML TBH, first one doesn't suit some people (immutability enforces some additional copies in certain situations), and SIMD requires huge libraries to handle, that's not suitable for SFML too.

I don't think this is really useful. I mean just use stb_image directly if the SFML interface doesn't suit your very specific needs.

I don't think loading an array of pixels is a very specific need.

Apropos, what are the real use cases for this?

I have to process a few hundred images repeatedly as fast as possible and SFML seems to be just right as a library to load an image (and sf::Color comes in handy too). The exact project that I'm working is reproducing certain images using genetic algorithms, but it's not really relevant.

7

Feature requests / Generalize and move ImageLoader outside of the priv namespace

« on: November 04, 2017, 12:26:27 am »

While sf::Image is really slow and rarely useful, loading images is a thing that most of us likes (right?). Now if someone implements his own class to keep and manage an image (I'm working on an immutable one right now) they need to first load it with sf::Image and then copy back, and we all know how slow allocations and copies can be. It leaves a programmer with two choices:

• Get over it and do those copies
• Switch to another library like Boost.GIL

Both approaches are pretty bad, first one wastes CPU time, second one – mine (and SFML's API is really neat compared to Boost.GIL).

The solution that I'd like to suggest is to:

• Move ImageLoader outside of the priv namespace
• Make it accept any pointer to a pre–allocated memory instead of a reference to the std::vector

What do you think?

8

Feature requests / Re: double click ?

« on: October 15, 2017, 07:03:27 pm »

It has to keep track of timing (i.e. remember when last click happened) and I can imagine situations where this could be undesirable. Anyway, it's up to SFML devs to decide, this feature, either as an event or in the way I described, has many use–cases, so it would be nice to have it.

9

Feature requests / Re: double click ?

« on: October 15, 2017, 06:53:53 pm »

Double–click event could actually have some considerable overhead, so I don't really want to see it being included in SFML. sf::Time getDoubleClickTime(), on the other hand, would be great.

10

General discussions / Re: is Migratable to SFML?

« on: October 11, 2017, 09:01:00 pm »

While SFML doesn't support SVG, I've written a library that wraps nanosvg into a nice SFML-like API, you can check it out here, and here's the documentation.

11

Feature requests / Re: Add sf::RenderTexture (ContextSettings&)

« on: September 06, 2017, 04:51:18 pm »

duplicate

12

Feature requests / Re: addColor method

« on: August 31, 2017, 07:16:50 pm »

Yep, there's no need for move tbh. I rarely used it in bigger projects.
It would be nice however, if sf::Sprite still did provide it. That's quite an important method for beginners, even though that's not a reason for it to be in sf::Transformable.

13

Feature requests / Re: Asynchronously transfer files via ftp

« on: August 09, 2017, 04:26:39 pm »

Well, I guess it's not a problem with types so small, that reading in the exact moment of writing is virtually impossible.

14

Feature requests / Re: Asynchronously transfer files via ftp

« on: August 08, 2017, 12:59:15 pm »

Ftp::TransferState::m_pointerToTransferedSize seems suspicious to me.
Is your code thread safe? I see a few possible data races in Ftp::downloadAsynced, Ftp::download, Ftp::TransferState::getTransferedSize and Ftp::TransferState::isTransferCompleted. All of them use said m_pointerToTransferedSize without any synchronization.
While it will probably work, it looks like an undefined behavior to me. No idea how I'd fix it tho, mutex is an overkill and neither SFML nor C++03 provide atomics.

15

Feature requests / Re: Vector2 and Color std::get overloads

« on: July 26, 2017, 10:19:43 pm »

Sooo, nevermind.
Longer version: I researched the topic once again as overloading stuff from std namespace seemed strange and I found out, that doing so is indeed sometimes used, but not recommended (like, really NOT RECOMMENDED) by the standard. TBH such code should be considered ill-formed and misdesigned. Oh, and in case of boost.geometry it was actually custom get function in a different namespace which was then inlined (that's how you call using namespace stuff;?) hence my image of said situation was wrong.

Man, killing off (is that even a correct collocation?) my own proposal feels bad.
Sorry for the fuss, I should have looked into it thoroughly.