Re: [paragui-users] PG_Application::SetBackground(...)

[Teunis Peters]

On 21 Feb 2003, Kamil Skalski wrote:

> > actually - having a redraw event sent to a background-manager makes more
> > sense (default = no manager == no message sent).  This will -very- badly
>
> I'm having something similiar in my project - I've set PG background to
> my surface and my background manager draws to this surface. Having
> redraw event would be more general and it should be in PG.
>
> > break opengl driver + maybe others too.
>
> I do not know paragl architecture, but the solution with events seems to

paragl is broken (it's another library) - it only works if a now-removed
SDL extension (SDLOPENGLBLIT) is available...
paragui/OpenGL works pretty standard except that it has an abstract of all
videowork - a "drawablesurface" for images and such.  Also, access to
videomemory is -zero- in opengl.  Also accessing opengl from multiple
threads is a great way to crash X (except for nVidia :).

> be good here. Of course rendering would require using proper driver or
> PG primitives, but it's needed anyway if somebody want to draw
> background using for example GL. Background drawing code needs to be
> changed in case of paragl, I can't imagine how drawing mutable surface
> could be fast here (glDrawPixels is quite slow). Most general solution
> would be to give derivable background-manager as you suggest with
> restrictions to use proper rendering style.

since I dump the images into opengl texturespace... *g* it's quite fast.
but anyways, changing texture information -isn't- fast...

anyways - as long as these rules are followed it should be okay:
        never render from multiple threads
        don't assume you have access to videomemory...
        always use the drawing-context rendering tools

G'day, eh? :)
        - Teunis