Topics

1

Window / Windowed fullscreen (a.k.a borderless fullscreen window)

« on: November 12, 2016, 08:10:34 am »

In order to switch between windowed and 'windowed fullscreen' (EDIT: also known as 'borderless fullscreen window') modes, I tried to re-call Window::create(), toggling between passing sf::Style::None + sf::VideoMode::getDesktopMode() and passing sf::Style::Default with the previously-saved window size.

• Is it the recommended practice?
• In Linux, the switch caused all letters to become white rectangles-of-some-sort, I had to reload all fonts to fix that. Windows did not seem to have this problem.
  Is it normal or something wrong on my side?
  Update: this seems to be specific to VirtualBox HW acceleration, unrelated to SFML.
  
• In Ubuntu Linux, there's that launcher at the left side of the screen, and the windowed-fullscreen window appeared next to it so the right side of the window went out of the screen.
  How do I make the window cover that launcher, or alternatively, is there any way to return the working area (in contrast to getDesktopMode() that returns the full resolution)?
  Update: this is an issue in Ubuntu Unity, unrelated to SFML (see below).
  
• In Windows, Alt-tabbing in windowed fullscreen mode out of the SFML window sometimes resulted in the screen becoming black, with its content gradually appearing following the mouse cursor.
  When I tried this code + calls to sf::Window::setSize() so that SFML was aware of the new size, this problem disappeared.
  Is it a known problem?

My configuration: desktop with one monitor, Win 7-64 & NV GPU (Aero disabled), Ubuntu 16.04 in a VM (HW accelerated).
SFML version: 2.4 with XCB removal commit.

2

General / Memory leak in SFML master (not occuring in 2.3.2) [WORKAROUND]

« on: February 08, 2016, 10:11:06 pm »

Using VS debug heap on the tutorial program, I get memory leaks in SFML master that do not occur in version 2.3.2.

The code is copied verbatim from the tutorial, with the addition of

#include <crtdbg.h>

and

::_CrtSetDbgFlag(::_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);

as the first line of main().

I use Windows 32 bit, VS 2012 Express, SFML & CRT statically-linked (and of course, run Debug version for the test). These leaks do not appear to accumulate over time (at least not in my project), but since they're new you may be interested in them.

(click to show/hide)

Detected memory leaks!
Dumping objects ->
{95} normal block at 0x03A8CE90, 48 bytes long.
 Data: < CK             > 20 43 4B 01 00 00 00 00 00 00 00 00 00 00 00 00
{94} normal block at 0x03A15B78, 8 bytes long.
 Data: <        > CD CD CD CD 90 CE A8 03
{93} normal block at 0x00522020, 48 bytes long.
 Data: < CK             > 20 43 4B 01 18 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.

Tracing the allocations with _CrtSetBreakAlloc():

• new ContextType(NULL) in GlContext::globalInit()
• new sf::Context in getInternalContext()
• new ContextType(sharedContext) in GlContext::create()

EDIT: the leaks were "fixed" by manually calling sf::priv::GlContext::globalCleanup() at the end of main().

3

Feature requests / Extending Font & Text to support multiple textures (bug fix)

« on: December 19, 2015, 08:22:35 am »

EDIT: This thread has come to implementing a bug fix for the problem of discarded glyphs when the texture used by Font and Text gets filled. It can be useful in case of big text, large alphabets or software renderers (e.g. Windows without GPU).

Use case: an application that can be resized by the user and draws some text in various character sizes. The size of the text varies according to the size of the window and the set of font glyphs that are needed changes over the course of the application.

The current behavior of SFML is to discard new glyphs if the underlying texture cannot be enlarged. The maximum texture size is implementation-dependent and is especially small in SW renderers (e.g. 512x512), resulting in some of the characters not displaying. To prevent that, I use some heuristics to calculate a limit on the character size and then use Text::setScale() to scale the font for the desired size. Large text can become a bit blurry on SW renderers, but this is more tolerable than characters not displaying.

The problem is that with multiple fonts, and new characters being added dynamically, it is not simple to estimate a safe limit on the character size that the maximum texture size will be able to accommodate. It would be easy to start high and decrease the limit on the fly if SFML provided a simple way of determining whether Font had discarded any glyphs for a given character size. (I guess I could redirect sf:err() to a stringbuf and test it at runtime, but I'm looking for a more standardized approach...)

4

Feature requests / Faster drawing of opaque primitives by disabling blending

« on: December 09, 2015, 01:23:17 am »

I have an application that draws many shapes, where most of them are opaque. Separate batches are maintained for opaque and non-opaque drawing operations, and they are rendered by calling RenderTarget::draw() with VertexArray.

In order to accelerate the drawing without modifying SFML, what I've been doing so far is manually disabled blending before opaque draw() calls. This has resulted in significant performance boost, but as a solution it feels a bit dirty. The cleaner alternative of using BlendNone was not as effective, resulting only in modest improvement way behind what disabling blending achieves.

I propose that as a performance optimization, SFML will disable blending when BlendNone is selected.

5

General / Static library files for RelWithDebInfo configuration omitting '-s' suffix?

« on: December 03, 2015, 09:11:03 pm »

Building the RelWithDebInfo configuration of SFML statically using Visual Studio on a CMake-generated solution seems to produce lib filenames without the '-s' suffix. The Release configuration of the same solution does add this suffix. Is it intentional?

I used CMake 3.3.2 on the latest SFML repository with BUILD_SHARED_LIBS=FALSE and SFML_USE_STATIC_STD_LIBS=TRUE, and built with VS 2012.

6

Feature requests / Saving memory bandwidth by not calling glTexCoordPointer()

« on: December 01, 2015, 08:10:27 pm »

For an application that makes heavy use of vector graphics that is rendered in batches with sf::VertexArray, using textures only infrequently for drawing text, performance might be improved by having RenderTarget::draw() not call glTexCoordPointer() in case that no texture nor shader is active, disabling the texture coords client state if needed.

Could you consider such an option for SFML?
Alternatively, how would you suggest to get a similar behavior with SFML without modifying its source code?