State of Pyglet GUIs

[Florian Bösch]

I've tested three GUI packages I could find and rated them in an
overview matrix, tell me when you think its incorrect.

http://codeflow.org/state_of_pyglet_guis.html

[Nicolas Rougier]

Thanks, nice overview.
One comment concerning glydget and draggable (if I've not
missunderstood your meaning).

You can actually drag/move/resize window:
* to drag, just click on a non sensitive widget (label).
* to resize, click on the lower-right corner.


Nicolas

[Richard Jones]

Needs to be another row "supports withgui API" :)

Richard

(really, there'll be a release soon, I promise!)

[Tristam MacDonald]

simplui does have a setuptools/easy_install package as of yesterday.

Also, the buggy collapsable widget is a pyglet bug, not a simplui bug (see http://code.google.com/p/pyglet/issues/detail?id=423)

--
Tristam MacDonald
http://swiftcoder.wordpress.com/

[Lynx]

Thanks, I appreciate the review!

You might want to note open source license type as well. kytten and
simplui are BSD license, while glydget is GPL.

Some other GUIs:

PyMT - multitouch-based UI - http://pymt.txzone.net/
PyGaG - one of several fixed-appearance GUIs - http://code.google.com/p/pygag/

Not an exhaustive list, there's at least one other fixed-appearance
GUI package out there I recall.

[Florian Bösch]

On Aug 17, 1:49 pm, Nicolas Rougier <nicolas.roug...@gmail.com> wrote:
> Thanks, nice overview.

> You can actually drag/move/resize window:
> * to drag, just click on a non sensitive widget (label).
> * to resize, click on the lower-right corner.

I see, tricky but dooable, matrix updated.

On Aug 17, 1:59 pm, Richard Jones <r1chardj0...@gmail.com> wrote:
> Needs to be another row "supports withgui API" :)

Done

On Aug 17, 2:39 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
> simplui does have a setuptools/easy_install package as of yesterday.

I didn't see it at: http://darkcoda.googlecode.com/svn/simplui/

> Also, the buggy collapsable widget is a pyglet bug, not a simplui bug (seehttp://code.google.com/p/pyglet/issues/detail?id=423)

I'll remove the yellow buggy as soon as that bug is fixed.

On Aug 17, 5:02 pm, Lynx <cw.l...@gmail.com> wrote:
> You might want to note open source license type as well.  kytten and
> simplui are BSD license, while glydget is GPL.

Done

> PyMT - multitouch-based UI -http://pymt.txzone.net/

> PyGaG - one of several fixed-appearance GUIs -http://code.google.com/p/pygag/

a-ha, more columns coming soon :)

Cheers,
Florian

[Tristam MacDonald]

On Mon, Aug 17, 2009 at 12:06 PM, Florian Bösch <pya...@gmail.com> wrote:

On Aug 17, 2:39 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
> simplui does have a setuptools/easy_install package as of yesterday.

I didn't see it at: http://darkcoda.googlecode.com/svn/simplui/

Of course not - setuptools packages live in the PyPI repository:

http://pypi.python.org/pypi/simplui/1.0.3

--

Also trying to figure out why you think the window dragging is buggy?

[Florian Bösch]

> On Aug 17, 2:39 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:> simplui does have a setuptools/easy_install package as of yesterday.

> > Also, the buggy collapsable widget is a pyglet bug, not a simplui bug (seehttp://code.google.com/p/pyglet/issues/detail?id=423)
> I'll remove the yellow buggy as soon as that bug is fixed.

Actually, I merged that fix in from svn some days ago, but I still get
a buggy display.

[Tristam MacDonald]

Buggy display is fine, that is fixed in the 1.0.4 alpha (official release coming soon).

Before patching that bug there was a hard crash, which is what I thought you were talking about.

[Florian Bösch]

On Aug 17, 6:35 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
> Also trying to figure out why you think the window dragging is buggy?

One time I ran it, when I dragged the widget it would move something
like double the distance I dragged (away from the mousepointer).
I ran it again, and it didn't do that, but I noticed that the mouse
pointer and widget kinda slide-apart during dragging.

[Nicolas Rougier]

In the updated array, pygag link points on simplui.

Nicolas

[Florian Bösch]

On Aug 17, 6:35 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
> Of course not - setuptools packages live in the PyPI repository:
> http://pypi.python.org/pypi/simplui/1.0.3

I've split that up somewhat. Package --> folder with __init__.py.
Distutils --> setup.py, README, LICENSE etc.
Also, If it's not in the source, it doesn't exist.

On Aug 17, 7:22 pm, Nicolas Rougier <nicolas.roug...@gmail.com> wrote:
> In the updated array, pygag link points on simplui.

Corrected

[Bruce Smith]

That looks really useful! Just one suggestion: a row for "date/version tested", since some of these packages are evolving rapidly.

- Bruce

[Richard Jones]

On 17/08/2009, at 9:59 PM, Richard Jones wrote:

>
> On 17/08/2009, at 8:43 PM, Florian Bösch wrote:
>> I've tested three GUI packages I could find and rated them in an
>> overview matrix, tell me when you think its incorrect.
>>
>> http://codeflow.org/state_of_pyglet_guis.html
>
> Needs to be another row "supports withgui API" :)

http://www.mechanicalcat.net/richard/log/Python/Something_I_m_working_on.6

Only label & button done at this time.

Richard

[René Dudfield]

hi,

anyone read about immediate mode guis? (imagine immediate mode
graphics VS retained mode graphics)

eg:

# show a button at 16,16 with 'Okay' on it.
if button(16, 16, "Okay"):
dostuff()

# write a textarea into value.
what_is_written = []
if textarea(16,16, what_is_written):
print what_is_written[0]


a more detailed video (40 minutes):
http://mollyrocket.com/861


Another style one is where the events are objects (like pygame) rather
than method calls, and are decoupled from the graphics.

On Aug 18, 10:21 am, Richard Jones <r1chardj0...@gmail.com> wrote:
> On 17/08/2009, at 9:59 PM, Richard Jones wrote:
>
>
>
> > On 17/08/2009, at 8:43 PM, Florian Bösch wrote:
> >> I've tested three GUI packages I could find and rated them in an
> >> overview matrix, tell me when you think its incorrect.
>
> >>http://codeflow.org/state_of_pyglet_guis.html
>
> > Needs to be another row "supports withgui API" :)
>

> http://www.mechanicalcat.net/richard/log/Python/Something_I_m_working...

[Florian Bösch]

On Aug 18, 11:36 am, René Dudfield <ren...@gmail.com> wrote:
> anyone read about immediate mode guis?  (imagine immediate mode
> graphics VS retained mode graphics)

It's an intriguing concept, but it has one major drawback. Input
sampling/processing and FPS are coupled inseparably. I daresay with
mice and keyboards and standard flat GUI applications (that do nothing
else), that's not a big problem. However, if you take into account
tablets, mice, 3d controllers, etc., they generate *huge* amounts of
events quickly at high sample rates, and to worsen things, often these
events need to go into physics simulations that need them more
frequently then you draw.

[René Dudfield]

yeah, the display is tied to the rendering of the gui elements.

However the event processing is not. You can store all events up to
each frame, and then only look at the events you care about each
frame. Your handle_events method for the imgui can run at a separate
frequency to the graphics display. This would set up the structures
where you imgui calls can inspect the previous frames events if they
need to.

... Richards withgui seemed a similar to the imgui style, but
different. Similar in that it avoids classes, and seems quite clear.

#withgui style
with gui.button('press me!'):
def on_click(*args):
print 'hello, world!'

#imgui style
if button(16, 16, "press me!"):
print 'hello, world!'

[Tristam MacDonald]

On Tue, Aug 18, 2009 at 6:46 AM, René Dudfield <ren...@gmail.com> wrote:

On Aug 18, 11:14 am, Florian Bösch <pya...@gmail.com> wrote:
> On Aug 18, 11:36 am, René Dudfield <ren...@gmail.com> wrote:> anyone read about immediate mode guis?  (imagine immediate mode
> > graphics VS retained mode graphics)
>
> It's an intriguing concept, but it has one major drawback. Input
> sampling/processing and FPS are coupled inseparably. I daresay with
> mice and keyboards and standard flat GUI applications (that do nothing
> else), that's not a big problem. However, if you take into account
> tablets, mice, 3d controllers, etc., they generate *huge* amounts of
> events quickly at high sample rates, and to worsen things, often these
> events need to go into physics simulations that need them more
> frequently then you draw.

yeah, the display is tied to the rendering of the gui elements.

However the event processing is not.  You can store all events up to
each frame, and then only look at the events you care about each
frame.  Your handle_events method for the imgui can run at a separate
frequency to the graphics display.  This would set up the structures
where you imgui calls can inspect the previous frames events if they
need to.

A bigger problem in my mind, is the performance (much more of a problem in python/pyglet than in C).

Because the GUI structure/layout can change at any time, and one maintains no state about previous frames, you pretty much have to redraw the entire GUI every frame, and you can't really utilise batching.

I wrote a small immediate-mode GUI toolkit for pyglet a while ago (not publicly available at the moment, sorry), and the lack of batching was the difference between 80 fps and simplui's 500+ fps.

Now, immediate-mode GUIs were intended for much lighter setups than simplui - i.e. just a handful of widgets for an in-game menu, and in that context they work fairly well, because the performance isn't too bad for that number of widgets.

[Florian Bösch]

On Aug 18, 12:46 pm, René Dudfield <ren...@gmail.com> wrote:
> However the event processing is not.  You can store all events up to
> each frame, and then only look at the events you care about each
> frame.  Your handle_events method for the imgui can run at a separate
> frequency to the graphics display.  This would set up the structures
> where you imgui calls can inspect the previous frames events if they
> need to.
>

> if button(16, 16, "press me!"):
>     print 'hello, world!'

For N events in the queue you have to call imgui code N times in the
event path (which somehow is some sort of context) and 1 time to draw
in draw path. Otherwise you'd loose events (like doubleclicks between
a frame).

Retained state between frames is a problem because you need to
remember it somewhere (like the button state). The proposed solution
to this is having a unique ID for each element that you can query out
of the context to hold the state. That's fairly fine for a single
button, but if you say draw your buttons from a loop or something it
becomes unpretty:

if button(context=context, id='mybutton', 16, 16, 'label'):
for item in somedata:
button(context=context, id='loop for somedata: %s' % id(item),
label=item.text)

Where it becomes completely hairy is how to implement layouts. Layouts
with inner-restrictions are still fairly doable, you just have to
commit to draw your stuff in exactly the right order as the layout can
use it (though luck if you don't happen to keep your data in exactly
the same order as the GUI). Layout with outer constraints, where you
might need to figure out offsets/sizes based on how elements push you
around left/right/top/down are virtually impossible to do.

[Florian Bösch]

On Aug 18, 12:52 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
> I wrote a small immediate-mode GUI toolkit for pyglet a while ago (not
> publicly available at the moment, sorry), and the lack of batching was the
> difference between 80 fps and simplui's 500+ fps.

Though I have a question about batched GUI rendering. It's my
understanding that for instance nvidia drivers reorder the primitives
in a vertex-list pretty much at random. If you draw two elements on
top of each other (like the frame background and the button
decoration), using batches, isn't it bound that happen that under some
random circumstances your graphics driver will completely foobar your
gui display?

[Tristam MacDonald]

On Tue, Aug 18, 2009 at 7:15 AM, Florian Bösch <pya...@gmail.com> wrote:

Where it becomes completely hairy is how to implement layouts. Layouts
with inner-restrictions are still fairly doable, you just have to
commit to draw your stuff in exactly the right order as the layout can
use it (though luck if you don't happen to keep your data in exactly
the same order as the GUI). Layout with outer constraints, where you
might need to figure out offsets/sizes based on how elements push you
around left/right/top/down are virtually impossible to do.

So then you go the hybrid-immediate route instead. Basically, your immediate mode code generates a tree, you update/layout/render the tree with a gui.end() call, and the tree is cached till next frame to provide coherency.

That allows you to run over the tree as many times as necessary to handle events, again to recalculate any sort of layout, and finally to render. On the flip side, the state reduction of immediate mode GUIs is pretty much thrown out the window.

Though I have a question about batched GUI rendering. It's my
understanding that for instance nvidia drivers reorder the primitives
in a vertex-list pretty much at random.

Certainly I have never encountered a driver that does this, and it would be more than a little problematic for everyone if it did - many applications depend on the order of elements in a vertex list (i.e. alpha-blended particle systems).

[Florian Bösch]

On Aug 18, 1:39 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
> Certainly I have never encountered a driver that does this, and it would be
> more than a little problematic for everyone if it did - many applications
> depend on the order of elements in a vertex list (i.e. alpha-blended
> particle systems).

Hmm, ic. But if you add/remove elements you need to recompile the
vertex buffer object completely from the document graph right?

[Alex Holkner]

I too have heard that maintaining vertex ordering is not a requirement
of OpenGL, but I haven't seen the relevant part of the specification
to be sure, nor have I seen it happen in practice. Incrementing Z for
each primitive in your draw order should be sufficient to maintain
that ordering though, even if the driver does like to reorder things
at the same Z depth.

Alex.

[Martin O'Leary]

2009/8/18 Alex Holkner <alex.h...@gmail.com>:

> I too have heard that maintaining vertex ordering is not a requirement
> of OpenGL, but I haven't seen the relevant part of the specification
> to be sure, nor have I seen it happen in practice.  Incrementing Z for
> each primitive in your draw order should be sufficient to maintain
> that ordering though, even if the driver does like to reorder things
> at the same Z depth.

Page 28 of the OpenGL 2.0 spec (the version I happen to have to hand,
I'm sure it's the same in other versions, albeit on a different page)
claims:

The effect of

DrawArrays (mode, first, count);

is the same as the effect of the command sequence

if (mode or count is invalid )
generate appropriate error
else
{
int i;
Begin(mode);
for (i=0; i < count; i++)
ArrayElement(first + i);
End();
}

with one exception: the current edge flag, texture coordinates, color,
color index, and normal coordinates are each indeterminate after the
execution of DrawArrays, if the corresponding array is enabled.

There are similar passages for MultiDrawArrays and DrawElements.
Unfortunately, I can't seem to find anywhere that explicitly states
that primitives within a Begin()/End() block can't be reordered, but
nor can I find anywhere that states that they can. The general feel I
get from the text is that the authors didn't expect this to happen,
but they didn't specify explicitly, as far as I can see.

Of course, just because the spec says so is no guarantee that any
given implementation will play nicely, but it's nice to have the
standard on your side.

Martin

[Tristam MacDonald]

OpenGL doesn't have any concept of 'same Z depth' during vertex processing, because a) there is no reason for the Z-axis to be perpendicular to the screen, and b) post-projection depth is only available after the vertices have been transformed.

In addition, you can't reorder vertices in isolation, because it would screw up the primitives. Instead you have to reorder entire primitives (quads, triangles, etc.), and that would be almost impossible to do by depth, because primitives can be mutually overlapping.

[Tristam MacDonald]

Would you mind also publishing which Hardware/Operating system the frames per second are tested on?

On my hardware (Intel X3100 under Mac OS X) simplui significantly outperforms glydget, and runs neck-and-neck with kytten.

 

[Nicolas Rougier]

On a macbook pro intel core 2 duo 2.8 GHz, simplui is rather slow (really slower than glydget).

That is weird considering you're also using a single batch. Do you have a specific program to test fps ? Do you need more information on my hardware ?

Also, for speed comparison, we could use a minimal setup with common widgets, same fonts, etc. Then we could compare pure speed (fps) and speed compared to a black window with only a clear call (this should give us speed more or less independently of hardware).

Nicolas 

[Florian Bösch]

On Aug 18, 3:59 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
> On my hardware (Intel X3100 under Mac OS X) simplui significantly
> outperforms glydget, and runs neck-and-neck with kytten.

Core2 Quad Q9300, GForce 8800GTS, Linux

[Greg Ewing]

Tristam MacDonald wrote:

> So then you go the hybrid-immediate route instead. Basically, your
> immediate mode code generates a tree, you update/layout/render the tree
> with a gui.end() call, and the tree is cached till next frame to provide
> coherency.

But this doesn't sound very different from a traditional
tree of widgets.

--
Greg

[Greg Ewing]

Florian Bösch wrote:

> The proposed solution
> to this is having a unique ID for each element that you can query out
> of the context to hold the state.

That's pretty ugly. Something I hate with a passion is a
GUI API that requires you to make up unique IDs for widgets.

> Where it becomes completely hairy is how to implement layouts.

That's another thing I was wondering. I much prefer to
write GUI layout code so that it builds things from the
bottom up most of the time. The IMGUI style would seem to
require calculating the layout from the top down.

--
Greg