Weston framerate (Re: bare bones opengl weston client sample)

[Pekka Paalanen]

On Fri, 7 Sep 2012 20:48:17 -0400
jegde jedge <bubbah.t at gmail.com> wrote:

> Sorry for the delay, my mail tool didn't link up this thread fro me.
> 
> I am running w/ DRM not X11; running weston in an X client was not
> adequate for my test app.
> I start by obtaining a virtual terminal ;init 3 ; then weston-launch
> This way I eliminate any X11 variables.
> You can see egl loading the dri driver when it starts up.
> If there is a better way please let me know.

Should be fine, I think.

> I run the the application with glut and weston using the same MESA
> stack that I compiled for weston.
> So, the only real difference is between glut/simple-egl and gnome(X11)/weston
> 
> My CPU usage is:
> weston - ~20+ fps - 3%
> glut(X11) - 60 fps - 17% - (60 is a hard limit for glut)
> tells me there is more to be had.
> This application renders  ~100 256x256 rgb textures on a moving map display.
> 
> I don't understand the wayland frame listener callback and how the
> wl_iterate works to drive redraw in simple-egl.

wl_display_iterate(), depending on the arguments, will receive and/or
send Wayland protocol messages. When it is receiving, it will dispatch
calls to your handlers, the frame listener callback for instance.

Usually the frame listener callback sets a flag, that the app can
repaint now. When wl_display_iterate() returns, you repaint, and the
protocol messages (posting a buffer) are sent on the next call to
wl_display_iterate().

simple-egl takes a shortcut and does not use a flag. It plays with the
frame callback object pointer to avoid posting buffers too often (to
avoid stalling in libEGL). The redraw function actually is the frame
callback to be called, so it is rendering and posting buffers as fast
as reasonable. More complex applications could use a better structure
than this.

> So, I am hoping I am just using it wrong.

I hope so too. Can you publish your code?

> I was hoping to do something similar to glutPostRedisplay() in a mouse
> drag event.
> This way I can start panning my textured tiles for a good test.

Yeah, you should add a flag for that, and check it when
wl_display_iterate() returns. The toytoolkit has the deferred_list for
it, called in display_run() where the main loop is, see window.c.

You don't see wl_display_iterate() explicitly in the display_run()
loop. wl_display_flush() calls wl_display_iterate() to send all pending
messages. The epoll has the Wayland fd in its list, and will end up
calling handle_display_data() when there are wayland messages to be
received. That will then call wl_display_iterate() to receive and
dispatch. The toytoolkit main loop is worth looking at.


Thanks,
pq