Subject: Re: [linux-audio-dev] Plugin GUIs
From: Paul Sladen (paul_AT_sladen.org)
Date: Sun Mar 25 2001 - 01:37:08 EET
On Sat, 24 Mar 2001, Juhana Sadeharju wrote:
> >Storing multiple frames for knobs etc. is best done as a strip or grid
(Completely irrelavent -- it's an implantation issue for X -- but hey):
I seem to remember doing something a while back with sequences of mouse
pixmap/masks. I stored them as a tall map; since, assuming linear storage
in memory, this means that each `frame' in stored consecutivally, and
therefore, more likely to be in the cache/same-page at once. Really, it
doesn't matter; hardware does it faster these days. Though, if you are
wantinh to use OpenGL acceleration, it is best to aim for square,
power-of-two images. either singularlly, or in large lumps.
One-frame-per texture means that the commonly used oned are more likely to
stay in the texture cache on the framebuffer; whereas putting everything
into the one texture means significantly less setup; *Selecting a new
texture is SLOW*. (everything is relative though, and an operation that
is `relatively slower' in hardware will still whip software.
> >(Multibit) alpha is important
> [ ... ]
> >Doesn't alpha blending really sting X servers, even with Xrender?
>
> I have had this idea of writing our own routines for alpha pixmaps.
> The final alphaless pixmap is then rendered from alpha pixmap composition.
*Don't* do it yourself, there is no point re-inventing the wheel again. I
would recommend using a library which can sit atop OpenGL and also do
things in software if there is only s/w OpenGL available.
IIRC Rasterman wrote a library that did pretty much that -- I think it was
called EVAS, but his website has been changed, and I can't find any
references to it; anyway, Enlightment uses it it to do all its fancy
Stretching/Bliting and the nice antialised text (again IIRC ;-).
> I have used my own simple renderer so far but if anyone has a real 3D
> renderer/modeler and some design skills, I would not mind if a common
> LAD GUI design is made: buttons, knobs, panels, LEDs, displays, etc.
[At the risk of starting a flame bate...]
What about standardising on GTK+ for the GUI layout -- Even going to the
point of just loading in `glade-xml' definitions of the interfaces. So
you say: "won't this bind us to a particular widget set?". I say this,
considering that most appear (I think!) are building/standardising around
GTK.
As has been shown with the GIMP; it's had really worth writing a Widget
Abstraction layer on top of another Widget Abstraction layout; port the
Widget set instead!!.
When (IF?) you support LADSPA-GUI on other platforms; then the Widget set
is probably already ported; or; how much trouble would it be to write an
import filter to translate the glade-xml definition on loading?
[Or am I missing the point?]
> Note: the images should be large (512x512?) and the final pixmaps
> would be resized in the application whenever user wants to resize
> GUI elements. Besides having suitable sized GUI elements, it would be
> advance to be possible to make often used GUI elements larger.
Um, is it really nessecary to store 1 *megabyte* of pixmap *per* `icon'.
(512*512*RGBA -- 2^(9+9+2) == 2^20)?
Paul
-- e: paul_AT_sladen.org t: 0115 922 7162
This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 15:40:05 EEST