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

Author Topic: SFGUI (0.4.0 released)  (Read 360113 times)

0 Members and 1 Guest are viewing this topic.

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI
« Reply #270 on: January 30, 2012, 07:55:17 am »
Quote
In SFGUI we have our lovely test app

Hehe. The problem with that is that the app itself changes a lot over time. For benchmarking something finished should be used. ;)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFGUI
« Reply #271 on: January 30, 2012, 08:18:35 am »
Quote
From what I can tell reading through the source, it would have been bottlenecked by the CPU instead of the GPU. Thus whether you used VAs, VBOs or IMs it probably wouldn't make any significant difference.

It tried: IM > VA > VBO.

Quote
Your usage of the word "Batch" to describe the class containing the data for a single drawable is also kind of misleading. They weren't really batched data and so could not profit from batching at all.

Your idea of uploading data into a single buffer and drawing all at once at the end was good. HOWEVER, if you only draw the data one object at a time they will be, as you saw, hardly any better than VAs or even IM.

I was accumulating vertices inside a sf::Batch until one state changed, so if drawing many sprites using the same texture, for example, I would end up drawing a single big chunk of geometry at the end.

Quote
Because you changed SFML a lot since then and cache states more effectively now and even use VAs as the primary drawing method, it would be nice to see how that old concept would fare in the current implementation.

I'll probably give it another try, yes.

Quote
And I'm curious, were these problems you speak of bugs/glitches or the flexibility/limitation kind of problems? I couldn't find any reports of problems related to the old drawing method while searching through those old threads.

I can't remember :(

Quote
1. Some way to identify/compare fonts among each other (name of the face or something).

In most use cases this will be useless: one can store the name when it loads the font, or use the sf::Font pointer as an identifier. Problems arise when you write a middleware, like SFGUI, and have no control on font instances. What kind of other use case could it be useful for?

Quote
2. Some way to tell SFML to wipe it's vertex cache.

I know that it's not very efficient, but currently SFML is not designed to be mixed with OpenGL this way. One must call Push/Pop/ResetGLStates in order to avoid messing up internal states. Supporting custom OpenGL commands in the middle of SFML rendering would require more work on my side, and probably a slightly different public API.
Out of curiosity, is it really a performance killer to call ResetGLStates once per frame?

Quote
3. Since you allow asking for a depth/stencil buffer, it would be nice to be able to clear those with RenderTarget::Clear() too instead of just the color. Now users have to resort to calling glClear() themselves which is horribly expensive.

I understand. However it would be weird to have something related to the depth buffer in the graphics module, which doesn't deal with depth at all.

Quote
4*. A standard benchmark spec that encompasses all areas of SFML to use as a performance measurement tool while trying to optimize SFML. This is one of those crucial things that I and others would need to know to experiment with making SFML faster.

I could show my own test app as a starting point, and maybe we could improve it together?
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
SFGUI
« Reply #272 on: January 30, 2012, 09:18:10 am »
I'm not sure if it's related, but there have been some bugs with the old render cache, e.g. this one.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFGUI
« Reply #273 on: January 30, 2012, 09:53:50 am »
Nop, this one is related to the state cache that was implemented after the batch renderer. Everything that involves sf::Renderer is the new implementation. The old one was using a sf::RenderQueue.
Laurent Gomila - SFML developer

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
SFGUI
« Reply #274 on: January 30, 2012, 12:16:36 pm »
Quote
In most use cases this will be useless: one can store the name when it loads the font, or use the sf::Font pointer as an identifier. Problems arise when you write a middleware, like SFGUI, and have no control on font instances. What kind of other use case could it be useful for?


Besides letting others manage the font resource themselves, probably none. I had an implementation with pointer comparisons, however that turned out to be a problem because GetDefaultFont() returns a reference, and to stay consistent all our fonts are passed around as references. We could just get the address of the sf::Font instance but that wouldn't work on temporary objects placed somewhere on the stack.

Quote
Out of curiosity, is it really a performance killer to call ResetGLStates once per frame?


We already minimized the state changes needed to be done when rendering the GUI. As such we want to manage the setting and resetting of the states ourselves and omit having to call ResetGLStates to reset things we didn't even touch. Calling ResetGLStates every frame was resulting in noticeably less performance.

Quote
but the best results will be achieved if you handle OpenGL states yourself (because you know which states have really changed, and need to be saved and restored)


That's what we want ;). And since when was a cache part of the OpenGL state machine? :P

Quote
I understand. However it would be weird to have something related to the depth buffer in the graphics module, which doesn't deal with depth at all.


Well you already let people create a depth buffer at Window creation although SFML doesn't make use of it itself. Keeping SFML "depth free" is therefore futile ^^.

Quote
I could show my own test app as a starting point, and maybe we could improve it together?


Would be a good starting point.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFGUI
« Reply #275 on: January 30, 2012, 12:31:01 pm »
Quote
We could just get the address of the sf::Font instance but that wouldn't work on temporary objects placed somewhere on the stack.

Your current implementation, which stores the font face pointer, breaks on this use case too, right?
In fact what's the difference between storing the internal font face pointer, and the pointer to the sf::Font instance?

Quote
Calling ResetGLStates every frame was resulting in noticeably less performance.

How many percents? ;)

Quote
That's what we want . And since when was a cache part of the OpenGL state machine?

Obviously this part is not yet very well supported in SFML :D
It definitely required more work. It would be really awesome if SFML and OpenGL could nicely be mixed together transparently.

Quote
Well you already let people create a depth buffer at Window creation although SFML doesn't make use of it itself. Keeping SFML "depth free" is therefore futile ^^.

The creation of the depth buffer is part of the window module, which clearly targets OpenGL and thus must provide features such as a depth buffer.
Adding a function to the graphics API would be weird.
But I understand that it's an issue.

Quote
Would be a good starting point.

I'll try to post it as soon as possible. It needs a little work before I can post it.
Laurent Gomila - SFML developer

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
SFGUI
« Reply #276 on: January 30, 2012, 12:46:41 pm »
Quote
Your current implementation, which stores the font face pointer, breaks on this use case too, right?
In fact what's the difference between storing the internal font face pointer, and the pointer to the sf::Font instance?


The answer to that lies in your sf::Font copy constructor :)

Quote
How many percents?


Can't remember exactly, but seeing the amount of code I wrote to avoid doing that, it must have been >10%.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFGUI
« Reply #277 on: January 30, 2012, 01:07:11 pm »
Quote
The answer to that lies in your sf::Font copy constructor

So you can handle copies of the same sf::Font instance, but not multiple sf::Font instances that would load the same font. Fair enough.

But to be honest, if FreeType allowed a font face to be copied, I would do a deep copy instead of using reference counting. The current implementation is just a workaround.

Anyway, providing more font information in sf::Font could be a good idea.
Laurent Gomila - SFML developer

raycrasher

  • Newbie
  • *
  • Posts: 24
    • View Profile
613 Image buttons
« Reply #278 on: February 11, 2012, 05:47:36 am »
Hello,

I am having some problems trying to create a window where I can display 618 image buttons for the user to choose from.

Trial 1
Loaded the 618 sprites into buttons, and added said buttons to a window. Result: compiles ok, loads ok (according to debugging), but hangs when the GUI updates or displays. 618 buttons loaded without images works though. Loading only a few sprites also works ok.

Trial 2
Loaded the whole spritesheet texture instead of individual sprites; I was thinking of drawing the buttons (with transparent background) over the image, like hot-spots. Displays ok, but I have a 1024x1024 spritesheet, and the window really needs to scroll in order to show the entire sheet. Besides, this is suboptimal, since I cannot sort the sprites according to category.

Trial 2.5
Tried using ScrolledWindow: Runs but does not display the texture. Then I noticed ScrolledWindow looks and feels like a control since it can't be dragged around, so I added it to a regular Window. Crash. Back to Trial 2.

Help! :(

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
SFGUI
« Reply #279 on: February 11, 2012, 06:03:18 am »
The only acceptable solution would be the first one. At the moment SFGUI is limited by the maximum texture size of the graphics card of the system it is running on. However you did mention that the spritesheet was (only) 1024x1024 which should fit in any not to ancient graphics card without issues.

I'm curious, does it also not work if you reduce the amount of buttons to say... 200 or 100? Or does it only not work at 618 buttons? The latter would indicate the limitation I mentioned earlier. The former would mean another bug somewhere. IIRC SFML should complain about OpenGL not being able to do stuff if you run it in debug mode. Always remember to check your console output when running something during development.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

raycrasher

  • Newbie
  • *
  • Posts: 24
    • View Profile
SFGUI
« Reply #280 on: February 11, 2012, 06:29:28 am »
Thanks for the quick reply!

I tried loading 128 buttons with images - hangs. Each would be about 10x10 to 70x70 pixels.

I will now try another variant of Trial 1 - Create a TabStrip-like control (Notebook, is it?), and separate the sprites by category into separate pages. Just need to know how would I implement scrolling through said buttons, since each category will have about 40 sprites each minimum. I'm looking at the test.cpp example as I type this, and yes, ScrolledWindow would be the way.

*copypasta mode* :D

Anyway, I was wondering why you used your own sfg::Image for image display - isn't sf::Sprite sufficient?

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
SFGUI
« Reply #281 on: February 11, 2012, 06:57:26 am »
sfg::Image is a SFGUI widget containing an Image. As such it can be manipulated in any way a widget would normally be manipulated (moved, resized, themed etc.). Internally it saves the image texture as an sf::Texture and the raw image data as an sf::Image. Using sf::Sprite doesn't come into question because of the new (optimized) way we render the GUI in the latest version. We take care of OpenGL ourselves and thus can refrain from using SFML itself for drawing.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Mars_999

  • Full Member
  • ***
  • Posts: 103
    • View Profile
    • Email
SFGUI
« Reply #282 on: February 18, 2012, 11:20:36 pm »
I just stumbled across this great project.

Now I am curious to know how can one skin/theme the GUI? or load buttons that are textured vs. a solid color....

Thanks!

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI
« Reply #283 on: February 19, 2012, 01:23:02 pm »
Mars_999: Check the SFGUI forum for the reply.

Mars_999

  • Full Member
  • ***
  • Posts: 103
    • View Profile
    • Email
SFGUI
« Reply #284 on: February 19, 2012, 03:22:17 pm »
Quote from: "Tank"
Mars_999: Check the SFGUI forum for the reply.


Thanks! Yeah the auto inform isn't working....