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? On Sep 10, 2012 6:49 AM, "Pekka Paalanen" <[email protected]> wrote:
> On Fri, 7 Sep 2012 20:48:17 -0400 > jegde jedge <[email protected]> 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 >
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
