Re: [paragui-users] a REALLY odd (but probably sensible) question about OpenGL and paragui (and some status updates)

[Teunis Peters]

On 1 Jun 2002, Alexander Pipelka wrote:

> Am Sam, 2002-06-01 um 09.34 schrieb Teunis Peters:
> > Is it possible to replace the PG_Application object (or another such) to
> > allow all SDL_Surfaces to talk to umm OpenGL textures? :)
>
> The OpenGL thing is truely a very sensible issue.
> Currently there isn't a satisfactory solution :((

I must admit unless one is working with 3D data or accelerated rendering,
OpenGL doesn't have a lot of use.  Well, accelerated rendering under X or
(apparently) future MacOS anyways.  Windows acceleration through either
GDI or DirectX is more efficient *sigh*.  And SDL supports all of the
framebuffer accels I know of...  well the standard ones anyways.
So THAT I guess depends on the target.

Embedded systems (except the not-really-particularily-embedded Xbox) tend
not to have 3D accel (or any accel) so paragui is quite uniquely well
suited to that environment :)

Umm I'm sort of working with a bizarre hybrid of videogame and GUI
actually... the GUI side's almost done :)  The videogame side will be a
while...  At this point - process management, XMLRPC (via http server) and
a few other components (some plugins) are all operational.  although a
good RPC api to talk to some-gui (eg: paragui) I'm still developing.
There's also a nicely operational python scriptengine designed to
communicate with this.  (the game I mentioned - the game core's already
operational I just think running it under a shell would be fun - the
artist I'm working with is away right now *sigh*)

intending to build something of a resume together actually.  I'm planning
on releasing this whole project opensource when I can afford to do so (ie:
I get payed enough by someone so I can afford rent and food *deep sigh*).

> > or more precisely is there an easy way? :)
>
> Don't think so.
> I've been thinking about something like a PG_OpenGLCanvas.
> This kind of object sould work like a container widget (e.g. PG_Widget,
> PG_Window,...) and blit all child widgets to a GL texture. Unfortunately
> a day is limited to 24 hours,... :)

*thinking*
Looking through the sources there's not a lot of dependancy on any
graphics lib....  I'm thinking that by either replacing SDL's drawing with
a plugin lib (or using glSDL :) that this could be solved easily :)

Running NULL-attached (root) widgets on OpenGL textures could work
actually.  hrm...  okay sounds like the tricky method's best.  Okay sounds
like fun :)

> I also think that thins kind of widget could not be done without
> changing the API (or breaking binary compatibility) -> Must be done int
> 1.1.x

I'll give it a looksee and see what happens - who knows, no? :)
I've tried a few OpenGL based GUIs through the years btw and they've all
had serious problems.  Most power goes to berlin-consortium (but -slow-
back then anyways) and anything GLUT based is broken-by-design (and prone
to slowness and crashing)

> Another things is that i don't use OpenGL (and probably won't do so in
> future).

It's useful some places.  Not others.  It fits my goals at the moment but
who's to say if it will in the future?

> > oh incidentally the problems I have with resize:
> > - window classes aren't setup for resize
> >     (ummm so I wrote one - it's just a small subclass of
> >     PG_Window that makes the lower-right corner do resize :)
> >     Anyone want? :)
>
> Sure. Any improvements are welcome :))

a really broken (ie: it crashes on resize) pgmpeg2 (yah my variation) is
attached complete with a resizeable window.  Chances are the resizeable
bits could be yanked out and shoved into the PG_Window object without
breaking anything...  I think...  (does adding private variables to a C++
class break binary compatibility?  g++ docs suggest no but history with
this kind of thing suggests otherwise).

and on layout objects:
        *hrm*. Have to get back to this.  They're only really useful in
windows that allow resizing (or quick-n-dirty dialogues)...  Java's model
(based on Fresco [Berlin :] I believe) is quite nice.

> > - smpeg has problems with resizes inside a window.  Seems to be a
> >   locking problem or something.  Causes X to crash the program
> >   quite nicely - and shows some threading problems with running it
> >   under paragui.
>
> Hmm. This one should be fixed for 1.0.2/1.1.0. When does it crash ? By
> embedding a pgmpeg object into a window ?

on desktop, in a window, where-ever.  The attached object (which by
doubleclicking on the video window tries to get it to fill the screen or
shrink it back to original size) does the expansion thing fine but crashes
when it's shrunk.  Doesn't matter if video's playing or not.  Alt-Enter
should switch between fullscreen and windowed - and it works fine for me.
Resizing the window causes it to crash... sometimes...

The resize code is based on plaympeg.c from smpeg's source.  Actually
checked some of the other code against that too...
one of these days I'll try and get it based on the MPEG class again
negating the need for some of the 'frameupdate' function's body.

> > - actually smpeg crashes under a few other circumstances.  A
> >   particular example is doing the same event loop as in the dblbuffer
> >   object.  Also a threading prob :)
>
> Please be more precise. We want to know all cases :))

Oh, THIS main loop:  (st is a holder class, st->app is the application :)
        Running it outside the holder class makes no difference in
        stability.

typical crash:
X Error of failed request:  BadValue (integer parameter out of range for
operation)
  Major opcode of failed request:  146 (MIT-SHM)
  Minor opcode of failed request:  3 (X_ShmPutImage)
  Value in failed request:  0xfe88
  Serial number of failed request:  84032
  Current serial number in output stream:  84033

Cause of this is usually based on more than one program attempting to
render to the screen (or SHM area) at the same time.  X is -not-
threadsafe under most conditions.  (it can be compiled threadsafe but I've
never encountered a distro that does it)

incidentally works fine under FB console.  Go figure :)

main loop follows:
------------------
  SDL_Event event;
  Uint32 then, now, frames;
  /* Loop, blitting sprites and waiting for a keystroke */
  frames = 0;
  then = SDL_GetTicks();
  done = 0;
  PG_Label* fps = static_cast<PG_Label*>(st->app->GetWidgetByName("fps"));
  while (!done)
    {
      /* Check for events */
      ++frames;
      while ( SDL_PollEvent(&event) )
        {
          st->app->PumpIntoEventQueue(&event);
        }
      now = SDL_GetTicks();
      if ( now > then )
        {
          fps->SetTextFormat("%2.2f FPS",  ((double)frames*1000)/(now-then));

          if((now-then) > 2000)
            {
              then = now;
              frames=0;
            }
        }

      st->app->DrawCursor();

G'day, eh? :)
        - Teunis

pgmpeg2-2.tar.bz2
Description: Binary data