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

[jegde jedge]

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" <ppaalanen at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120910/2d944d73/attachment.html>