Messages

1

Feature requests / Re: Request: allow either move semantics or direct pointer access in sf::Image

« on: March 29, 2013, 05:19:14 pm »

Hey, wonderful response everyone.

What I was originally trying to do was create a SkiaImage type derived from Image that could allow Skia to render directly into it's internal buffer without a copy operation.  However, I realize that I came in while still looking at the docs and didn't notice that sf:Texture took raw Uint8 pointers, which makes it possible to do pretty much everything I need without deriving from the sf:Image object (Yay! Design!).

I realize that while I'd still love to see a C++11 style constructor with move semantics (which sounds like it is on the way), I can work with this in a different way.

Thanks!

2

Feature requests / Request: allow either move semantics or direct pointer access in sf::Image

« on: March 29, 2013, 08:47:19 am »

I'm looking at doing some work with Skia, and I want to create a rendering context that renders directly into an Image object.  Unfortunately, the current Image implementation blocks this without performing an expensive texture copy for every render.  There are several solutions that could work for me:

1) Change from private to protected visibility for m_pixels
2)  Provide a non-const getPixelsPtr
3) Give me a c++11 -style constructor or factory function with move semantics, e.g:
     Image(unsigned int width, unsigned int height, std::vector<Uint8> &&pixels);

4) Provide:
     void sf::Image::create(unsigned int width, unsigned int height, std::vector<Uint8> &pixels);
which performs an actual std::vector<>::swap() or std::swap() so that only a pointer exchange occurs.

Out of these, 1) is probably the best.

If one of these could make it into 2.0 it would save me (and I suspect others) from having to create a modified version of SFML to run on my engine.