Messages

1

General / Re: event-driven rendering (instead of rendering at each main loop iteration)?

« on: November 13, 2012, 09:15:07 pm »

I'm not sure I see the problem.  When you don't want the limit, don't set the limit.  It's not like you need to make a choice now and it's set in stone for every application you generate from here on out (or even within a single application.) Also if you don't want to update/render when there are no events processed, don't.

i tried to do it like in your code suggestion. The problem is that it doesn't process expose events. Therefore, when a window or parts of it has to be redrawn (for example because some drag&drop or window moving partially in front of it) i don't get any event for that => the parts of my window that have been lost are not redrawn.

2

General / Re: event-driven rendering (instead of rendering at each main loop iteration)?

« on: November 12, 2012, 09:43:20 pm »

thanks for the quick answer.
Actually, i do come from such gui libraries (i'm mainly using Qt these last years but have used bot wx and gtk before).
My intent though was to switch my gui stuff to OpenGL only to cut the bloat (these frameworks have become terribly bloated),  be more independent of them and optimize my GUI. Besides, i do need full control of the main loop and the ability to do full speed OpenGL and realtime rendering sometimes too. Since i'm only doing OpenGL anyways, SFML would fit nicely as a system abstraction layer for my purposes except for the fact that i don't see how to do that expose event thingie.
Unfortunately, solving the CPU hogging with an artificial frame rate limitation would hurt me when i actually need the full frame rate (e.g. when dragging stuff around or in widget change animations).
Now i do understand that my use case may diverge somehow from that of most SFML users and its primary architectural target, but if it was just that nobody needed to pass through the expose events of the window system so far, then i guess it shouldbe feasable to add that... if it's mostly just that, then i would give it a try.
Or does the "not designed to work like this" imply that there might be some other, bigger problems with using SFML for desktop applications that use event-based rendering most of the time?

3

General / event-driven rendering (instead of rendering at each main loop iteration)?

« on: November 12, 2012, 08:40:32 pm »

Hi

the examples i tried work nicely, but they hog the CPU because the window is re-drawn at every iteration of the main loop. While this is certainly what you'd want for an action game that has to re-render constantly as fast as possible because every frame is different, it's not what you'd want for an event-driven application where the rendering content only rarely changes (e.g. a drawing program or actually most type of non-game application software that doesn't show animations). So i tried to change the event processing so as to only redraw the window when either of these happens:
* resize
* exposure (even partial; e.g.: some other window is dragged over my window and hides a part of it during this process. Each obstructed part of my window has to be redrawn when the other window isn't hiding it any more)
* reactions to user interaction (e.g. ui elements changing appearance because of a click on an active region)

My problem:
When i look at sf::Event::EventType, i do see sf::Event::Resized  but no event type that would correspond to an Expose Event. Is there something i'm missing there? I don't see how to develop an event-driven main loop (i.e. one that does not constantly re-render even if nothing happens) without an expose event. So how would you guys do it?

Is there some example somewhere that would use sfml like that?

4

General discussions / Re: SFML 2.0 RC

« on: July 05, 2012, 07:51:49 pm »

just tried the RC, looks nice. Just one weird quirk:
i installed it into a custom directory.
however, when i set the PKG_CONFIG_PATH accordingly and try pkg-config --libs --cflags sfml-all
it shows the following:
-I/home/laurent/release/2.0-rc/sfml/SFML-2.0-rc/include  -L/home/laurent/release/2.0-rc/sfml/SFML-2.0-rc/lib -lsfml-system -lsfml-window -lsfml-graphics -lsfml-audio -lsfml-network 

alas, neither my name nor my user login is laurent, so i guess this directory is hardcoded somewhere.