I will post code when I get to the hotel tonight. Basically, I simply ifdef'd in redraw() in simple-egl and branched into my draw routine. I will post both wl_client and glut front ends. Thank you for your help. Is there a place that describes any threading model there may be in iterate or flush that could cause a block? <div class="gmail_quote">On Sep 10, 2012 6:49 AM, "Pekka Paalanen" <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Fri, 7 Sep 2012 20:48:17 -0400 jegde jedge <<a href="mailto:bubbah.t@gmail.com">bubbah.t@gmail.com</a>> 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 </blockquote></div>