Re: Weston framerate (Re: bare bones opengl weston client sample)
On Tue, 18 Sep 2012 12:52:12 -0400 jegde jedge wrote: > the (window == NULL) was a remnant of prior experimentation. > I have removed and confirmed > There are no other eglSwapBuffer() calls anywhere in the code. Ok, good. > I will produce a simple test app that illustrates my problem. > Bottom line is: > glut = 60 fps > wayland = 20 fps > > Hopefully, in doing so, it will flush out what I am missing. That would be nice. Make it without all the #ifdefs, too, please. Did you ever check with 'gears' that you actually can get approximately to monitor refresh rate under Weston? It prints fps to stdout. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
the (window == NULL) was a remnant of prior experimentation. I have removed and confirmed There are no other eglSwapBuffer() calls anywhere in the code. I will produce a simple test app that illustrates my problem. Bottom line is: glut = 60 fps wayland = 20 fps Hopefully, in doing so, it will flush out what I am missing. Thanks again. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
On Fri, 14 Sep 2012 10:32:03 -0400
jegde jedge wrote:
> Sorry about the delay.
> I flew 8 legs in 4 days this week.
>
> Here are the mains for both the glut and Wayland instance of my test
> application.
>
> uMfdInit, uMfdDraw, and c->controller->event() are the interface
> functions, solely used by both implementations.
> The code under the hood is IDENTICAL. (with the exception of
> glutPostRedisplay() for pan gestures.)
>
> In MainWayland you will see simple-egl.c conditionally compiled for my
> application using
> HAVE_GLES2 and SIMPLE_EGL
> Both MainWayland.c and MainGlut.c use the functions above in the same way.
>
> To recap I am hoping to allow unbounded redraws for testing purposes only.
I don't think Mesa implements that for Wayland windows yet. You might
be able to get it by using some vsync related extensions, but by
default, you will be capped to the monitor refresh rate anyway, as
eglSwapBuffers will block.
Remember, that your repaint loop is (must be, to avoid a deadlock in
Mesa!) driven by the frame callback, which you will get only after a
flip (monitor refresh). That alone limits you to monitor refresh rate.
IOW, you must not call redraw() until you have received the frame
callback set in the previous redraw (I tried to explain this earlier,
and it is the key to fluent rendering for now).
If you want uncapped, better render to FBO or pbuffer.
>
>
>
All the #ifdefs really make it hard to read.
You seem to be getting a NULL 'window' in some functions, that should
not happen.
Other than that, I couldn't see a real problem in the middle of all
that. Are you also sure, that the code you pasted below is the only
place to ever call eglSwapBuffers()?
> static void
> redraw(void *data, struct wl_callback *callback, uint32_t time)
> {
> struct window *window = data;
> struct wl_region *region;
>
> if (callback)
> wl_callback_destroy(callback);
>
> if (window)
> if (!window->configured)
> return;
>
> uMfdDraw(c);
> eglSwapBuffers(window->display->egl.dpy, window->egl_surface);
>
>
> if (window)
> {
> window->callback = wl_surface_frame(window->surface);
> wl_callback_add_listener(window->callback, &frame_listener, window);
> }
If you ever get here with window=NULL, a new frame callback is not
requested, therefore there is nothing to trigger rendering anymore. You
are not rendering in a continuous loop. In fact, I'm suprised your
application renders more than one frame ever, if window=NULL.
I hope these comments give you some ideas where to look.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
Sorry about the delay.
I flew 8 legs in 4 days this week.
Here are the mains for both the glut and Wayland instance of my test
application.
uMfdInit, uMfdDraw, and c->controller->event() are the interface
functions, solely used by both implementations.
The code under the hood is IDENTICAL. (with the exception of
glutPostRedisplay() for pan gestures.)
In MainWayland you will see simple-egl.c conditionally compiled for my
application using
HAVE_GLES2 and SIMPLE_EGL
Both MainWayland.c and MainGlut.c use the functions above in the same way.
To recap I am hoping to allow unbounded redraws for testing purposes only.
#include "uMfd.h"
#include
#include
#include
#include
extern UmfdContext *c;
void glutMotion(int x, int y)
{
c->controller->event(c, drag, x, y);
}
void glutMouse(int button, int state, int x, int y)
{
if (button == GLUT_LEFT_BUTTON)
{
if (state == GLUT_UP)
c->controller->event(c, leftUp, x, y);
else
c->controller->event(c, leftDown, x, y);
}
if (button == GLUT_RIGHT_BUTTON)
{
if (state == GLUT_UP)
c->controller->event(c, rightUp, x, y);
else
c->controller->event(c, rightDown, x, y);
}
}
void keyboardIn(unsigned char key, int x, int y)
{
fprintf(stderr, "key-%x; x-%d; y-%d\n", 0x00ff & key, x, y);
switch(key & 0xff)
{
case GLUT_KEY_UP:
c->controller->event(c, upArrow, 0, 0);
break;
case GLUT_KEY_DOWN:
c->controller->event(c, downArrow, 0, 0);
break;
case GLUT_KEY_RIGHT:
c->controller->event(c, rightArrow, 0, 0);
break;
case GLUT_KEY_LEFT:
c->controller->event(c, leftArrow, 0, 0);
break;
// PC menu tooggle
case 0x1b:
fprintf(stderr, "glut KB esc menu");
c->controller->event(c, menu, 0, 0);
break;
case '-':
case '_':
case 0x32:
c->controller->event(c, zoomOut, 2, 2);
break;
case '=':
case '+':
case 0x33:
c->controller->event(c, zoomIn, 3, 3);
break;
// PC menu select
case 0xa:
case 0xd:
fprintf(stderr, "glut KB enter menu select\n");
c->controller->event(c, menuSelect, 0, 0);
break;
}
}
void glutDraw()
{
uMfdDraw(c);
}
void glutIdle()
{
uMfdProcess(c);
//uMfdDraw(c);
}
void glutResize(int width, int height)
{
c->view->resize(c, width, height);
}
int InitializeGraphics()
{
int argc= 0;
char *argv[] = {"one", "two"};
fprintf(stderr, "pc glut init\n");
glutInit(&argc, argv);
/* defining the window with double buffer */
glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH);
glutEnterGameMode();
if(0)
{
glutInitWindowSize(p.width, p.height);
glutInitWindowPosition(100, 100);
}
//glutFullScreen();
//glutCreateWindow("FBCB2 uMFD 'micro'");
glutDisplayFunc(glutDraw);
glutMotionFunc(glutMotion);
glutPassiveMotionFunc(glutMotion);
glutMouseFunc(glutMouse);
glutIdleFunc(glutIdle);
glutSpecialFunc((void*)keyboardIn);
glutKeyboardFunc((void*)keyboardIn);
glutReshapeFunc(glutResize);
glFrontFace(GL_CCW);
glShadeModel(GL_SMOOTH);
glEnable(GL_CULL_FACE);
glDepthFunc(GL_LEQUAL);
glEnable(GL_DEPTH_TEST);
//glDepthMask(GL_TRUE);
//glEnable(GL_NORMALIZE);
//glEnable(GL_COLOR_MATERIAL);
//glEnable(GL_TEXTURE_2D);
glDisable(GL_STENCIL_TEST);
glDisable(GL_ALPHA_TEST);
glDisable(GL_SCISSOR_TEST);
{
GLfloat fSizes[2];
glGetFloatv(GL_SMOOTH_POINT_SIZE_RANGE, fSizes);
fprintf(stderr, "%f %f\n", fSizes[0], fSizes[1]);
}
glClearColor(0.5f, 0.5f, 0.5f, 1.0f);
printf("(e)GL engine initialized\n");
return(1);
}
int main(int argc, char *argv[])
{
/* perform graphics initialization here */
if (InitializeGraphics() == 0)
{
fprintf(stderr, "failed to initialize uMfd graphics interace\n");
return(1);
}
/* start up the plugins */
if (uMfdInit(argc, argv, UMFD_CONTEXT_GLUT) == 0)
{
fprintf(stderr, "failed to initialize uMfd plugin interface\n");
fprintf(stderr, "failed to initialize uMfd plugin interface\n");
return(1);
}
/* main render loop if needed */
glutMainLoop();
uMfdFree(c);
/* return success */
return(0);
}
/*
* Copyright © 2011 Benjamin Franzke
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the above copyright notice appear in all copies and that both that copyright
* notice and this permission notice appear in supporting documentation, and
* that the name of the copyright holders not be used in advertising or
* publicity pertaining to distribution of the software without specific,
* written prior permission. The copyright holders make no representations
* about the suitability of this software for any purpose. It is provided "as
* is" without express or implied warranty.
*
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
Re: Weston framerate (Re: bare bones opengl weston client sample)
On Mon, 10 Sep 2012 07:56:22 -0400 jegde jedge wrote: > Is there a place that describes any threading model there may be in iterate > or flush that could cause a block? Libwayland objects are not thread-safe. wl_display_iterate() can block, if you call it with READABLE and there are no events already waiting to be read. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
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" wrote: > On Fri, 7 Sep 2012 20:48:17 -0400 > jegde jedge 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 wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
On Fri, 7 Sep 2012 20:48:17 -0400 jegde jedge 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 wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
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. 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. So, I am hoping I am just using it wrong. 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. On Fri, Sep 7, 2012 at 2:16 AM, Pekka Paalanen wrote: > On Thu, 6 Sep 2012 11:25:20 -0400 > jegde jedge wrote: > >> Thank you so much, that did the trick! >> >> Next Question :) >> On the same code, on the same hardware... >> I am getting the glut 60 fps limit when running my app using the glut >> front end via >> gnome and X. >> I am getting ~24 fps using the simple-egl front end on top of wayland. >> I also noticed the display using wayland likes to hover around 20 fps. >> >> Is there some kind of throttle built into the frame rate for the >> redraw callback? > > Hi, > > could you remind us, are you running Weston with the X11 or DRM backend? > > If you use the X11 backend, sloppy framerates are expected. X has no > method of telling the X application (weston) that the image it posted > has now hit the screen. Therefore the X11 backend fakes it by using a > timer to blindly to trigger this "image hit the screen" callback. > Obviously that is very flakey and inaccurate, but cannot really do any > better. > > However, if you are on DRM backend, it is worth investigating. > > > Thanks, > pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Weston framerate (Re: bare bones opengl weston client sample)
On Thu, 6 Sep 2012 11:25:20 -0400 jegde jedge wrote: > Thank you so much, that did the trick! > > Next Question :) > On the same code, on the same hardware... > I am getting the glut 60 fps limit when running my app using the glut > front end via > gnome and X. > I am getting ~24 fps using the simple-egl front end on top of wayland. > I also noticed the display using wayland likes to hover around 20 fps. > > Is there some kind of throttle built into the frame rate for the > redraw callback? Hi, could you remind us, are you running Weston with the X11 or DRM backend? If you use the X11 backend, sloppy framerates are expected. X has no method of telling the X application (weston) that the image it posted has now hit the screen. Therefore the X11 backend fakes it by using a timer to blindly to trigger this "image hit the screen" callback. Obviously that is very flakey and inaccurate, but cannot really do any better. However, if you are on DRM backend, it is worth investigating. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: bare bones opengl weston client sample
I forgot to mention. its on 945GME glut 60 fps uses 17%cpu wayland 24 fps uses 3% cpu I am hoping for an apples to apples. ! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: bare bones opengl weston client sample
Thank you so much, that did the trick! Next Question :) On the same code, on the same hardware... I am getting the glut 60 fps limit when running my app using the glut front end via gnome and X. I am getting ~24 fps using the simple-egl front end on top of wayland. I also noticed the display using wayland likes to hover around 20 fps. Is there some kind of throttle built into the frame rate for the redraw callback? Thank you. On Wed, Sep 5, 2012 at 8:59 PM, Kristian Høgsberg wrote: > On Wed, Sep 5, 2012 at 8:11 PM, jegde jedge wrote: >> Thanks, >> I tried that route. it is a gles2 not gles or opengl example; and that >> will not work with the fixed function pipeline functions like >> glPushMatrix et.al. > > Sure, it's a gles2 example, but it shows you how to get a minimal > egl/gles2 client working under wayland. I figured you'd want to > replace the gles2 code with your own code anyway, and yes, it is just > a matter of using EGL_OPENGL_API, removing the context attributes and > linking to libGL. > > Kristian > >> I went with the gears example since it binds the OPENGL API but it >> uses the window/toytoolkit/libshared stuff with cairo >> and I don't have enough insight to what is needed and what isnt. >> >> Is it as simple as replacing line 131: >> ret = eglBindAPI(EGL_OPENGL_ES_API); >> with >> EGL_OPENGL_API and linking against GL/libGL instead of GLES2/libGLES2 ? >> >> Thank you. >> I'll try in the morning. >> >> >> On Wed, Sep 5, 2012 at 4:51 PM, Kristian Høgsberg wrote: >>> Right under your nose: >>> >>> http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c >>> >>> Kristian >>> >>> On Wed, Sep 5, 2012 at 4:29 PM, jegde jedge wrote: Is there a bare bones open gl example that implemnts the bare minimum needed to get a wayland surface and begin drawing using openGL? I'm having a hell of a time porting my GLES1 application to run as a wayland/weston client. This application has run on psp, iPone, glut, and android. Since It is gles I used the weston gears client application as a template. Basically, I just inserted the hooks to call my applications draw routines using the egl config already provided. I have tiled textured maps working, but I am having some hoaky results with the first texture that it loaded. I would like to eliminate cairo pixman, libtoytoolkit, libshare.a as variables. I just dont see an example to do openGL with only wl_xxx() calls. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: bare bones opengl weston client sample
On Wed, Sep 5, 2012 at 8:11 PM, jegde jedge wrote: > Thanks, > I tried that route. it is a gles2 not gles or opengl example; and that > will not work with the fixed function pipeline functions like > glPushMatrix et.al. Sure, it's a gles2 example, but it shows you how to get a minimal egl/gles2 client working under wayland. I figured you'd want to replace the gles2 code with your own code anyway, and yes, it is just a matter of using EGL_OPENGL_API, removing the context attributes and linking to libGL. Kristian > I went with the gears example since it binds the OPENGL API but it > uses the window/toytoolkit/libshared stuff with cairo > and I don't have enough insight to what is needed and what isnt. > > Is it as simple as replacing line 131: > ret = eglBindAPI(EGL_OPENGL_ES_API); > with > EGL_OPENGL_API and linking against GL/libGL instead of GLES2/libGLES2 ? > > Thank you. > I'll try in the morning. > > > On Wed, Sep 5, 2012 at 4:51 PM, Kristian Høgsberg wrote: >> Right under your nose: >> >> http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c >> >> Kristian >> >> On Wed, Sep 5, 2012 at 4:29 PM, jegde jedge wrote: >>> Is there a bare bones open gl example that implemnts the bare minimum >>> needed to get a wayland surface and begin drawing using openGL? >>> >>> >>> I'm having a hell of a time porting my GLES1 application to run as a >>> wayland/weston client. >>> >>> This application has run on psp, iPone, glut, and android. >>> >>> Since It is gles I used the weston gears client application as a template. >>> Basically, I just inserted the hooks to call my applications draw >>> routines using the egl config already provided. >>> >>> I have tiled textured maps working, but I am having some hoaky results >>> with the first texture that it loaded. >>> >>> I would like to eliminate cairo pixman, libtoytoolkit, libshare.a as >>> variables. >>> I just dont see an example to do openGL with only wl_xxx() calls. >>> ___ >>> wayland-devel mailing list >>> wayland-devel@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: bare bones opengl weston client sample
Thanks, I tried that route. it is a gles2 not gles or opengl example; and that will not work with the fixed function pipeline functions like glPushMatrix et.al. I went with the gears example since it binds the OPENGL API but it uses the window/toytoolkit/libshared stuff with cairo and I don't have enough insight to what is needed and what isnt. Is it as simple as replacing line 131: ret = eglBindAPI(EGL_OPENGL_ES_API); with EGL_OPENGL_API and linking against GL/libGL instead of GLES2/libGLES2 ? Thank you. I'll try in the morning. On Wed, Sep 5, 2012 at 4:51 PM, Kristian Høgsberg wrote: > Right under your nose: > > http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c > > Kristian > > On Wed, Sep 5, 2012 at 4:29 PM, jegde jedge wrote: >> Is there a bare bones open gl example that implemnts the bare minimum >> needed to get a wayland surface and begin drawing using openGL? >> >> >> I'm having a hell of a time porting my GLES1 application to run as a >> wayland/weston client. >> >> This application has run on psp, iPone, glut, and android. >> >> Since It is gles I used the weston gears client application as a template. >> Basically, I just inserted the hooks to call my applications draw >> routines using the egl config already provided. >> >> I have tiled textured maps working, but I am having some hoaky results >> with the first texture that it loaded. >> >> I would like to eliminate cairo pixman, libtoytoolkit, libshare.a as >> variables. >> I just dont see an example to do openGL with only wl_xxx() calls. >> ___ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: bare bones opengl weston client sample
Right under your nose: http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c Kristian On Wed, Sep 5, 2012 at 4:29 PM, jegde jedge wrote: > Is there a bare bones open gl example that implemnts the bare minimum > needed to get a wayland surface and begin drawing using openGL? > > > I'm having a hell of a time porting my GLES1 application to run as a > wayland/weston client. > > This application has run on psp, iPone, glut, and android. > > Since It is gles I used the weston gears client application as a template. > Basically, I just inserted the hooks to call my applications draw > routines using the egl config already provided. > > I have tiled textured maps working, but I am having some hoaky results > with the first texture that it loaded. > > I would like to eliminate cairo pixman, libtoytoolkit, libshare.a as > variables. > I just dont see an example to do openGL with only wl_xxx() calls. > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
