Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: sf::WindowBase vs sf::Window vs sf::RenderWindow  (Read 1580 times)

0 Members and 1 Guest are viewing this topic.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10390
    • View Profile
    • development blog
    • Email
sf::WindowBase vs sf::Window vs sf::RenderWindow
« on: April 22, 2022, 12:51:20 am »
Currently we have three different window classes.

Originally, sf::Window was a basic window that creates an OpenGL context, but without SFML specific draw functionality. And sf::RenderWindow which does add those SFML specific draw functionalities.

The much later sf::WindowBase was introduced as a window that doesn't have an OpenGL context and to retain the API compatibility for SFML 2.

With SFML 3 being in development, thus we're no longer bound to API compatibility and with a glimpse into a future, where we might have multiple rendering backends...

What API would you propose for the window setup if you were to start completely fresh?
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://dev.my-gate.net/

wintertime

  • Sr. Member
  • ****
  • Posts: 255
    • View Profile
Re: sf::WindowBase vs sf::Window vs sf::RenderWindow
« Reply #1 on: April 23, 2022, 11:39:50 am »
Nice that you finally start cleaning up the codebase for SFML3.

I think, there was too much mixed into the Window.
A cleaner API may be to have a Window, which only cares about the basic window settings and input.
Then have an abstract Context class providing a hopefully future-proof abstraction. The first derived class from this could then be the OpenGLContext. Later other APIs could have their own.
I'd hope it can be avoided and just the Context used, but if necessary make a Graphics class that is given a Context, which is used for everything that the SFML Graphics package additionally needs.
« Last Edit: April 23, 2022, 11:45:17 am by wintertime »

barnack

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
Re: sf::WindowBase vs sf::Window vs sf::RenderWindow
« Reply #2 on: January 23, 2023, 09:24:51 pm »
Nice to see the windows are being argued about.
Imo the biggest problem is that the library's modularity is lost with the windowing system.
While we can have SFML's windowing without SFML's drawing, we can't have SFML's drawing without SFML's windowing. That I think should be addressed for SFML 3.

There needs to be a way to let the users provide their own window and NOT override the user's (or third party library) underlying windowing system management.

I can't speak for other OSs as I'm focused on Windows; on Windows if the user passes his own HWND, SFML will replace the user's window procedure with its own.

Instead a more generalized drawing framework could give an interface to which the user can pass OS level events to the windows so SFML can handle the messages it needs to handle.

In short, if I use SFML's drawing on my own non-SFML windows, I want SFML to deal with resizing events but not everything else.

For example I do have a more generalized windowing framework here (https://github.com/Sephirothbahamut/CPP_Utilities_MS), that lets the user add his own "modules" to the window, so you can write a "direct2d", and "sfml" or an "opengl" module that handle swapchain related stuff but let other modules handle other things.

A valid option would be a window-specific rendertarget type with an "on resize" method that takes the new window size. The user window is expected to call that method with the resize event, may it be from a WndProc on window, a callback on glfw, or the size event from sfml's own window.

Same for any other event that a window render target may need, although to be honest the resize event is the only one I can think about right now.

 

anything