Subject: Re: [linux-audio-dev] proposed initial DTD for LADSPA-gui-xml
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue Nov 28 2000 - 06:17:44 EET
>Paul, does you code currently check if the port value has
>really changed between two updates ?
>I'm thinking about something like:
>
>while(1) {
> sleep n msecs
> for each widget {
> if(widget->port->value != widget->port->old_value) widget->update();
> }
>}
of course. at least where i judge it to matter.
>Next topic:
>pixmap based slider movement:
>
>in your previous mail you said you do not use moving sliders, but you use
>a set of fixed pixmaps.
>Assume that one want large faders which move with single pixel precision.
Absurd. Hows that for an answer ? Its just a silly idea. You can't
possibly detect single pixel motion unless its an oscillation (ie. up
1 pixel, down 1 pixel) with a fairly high-frequency. even then, many
people might not really notice it.
Thats why I use what I've empirically determined to be a
reasonably-sized set of them. For h- and v-motion widgets, that size
is unfortunately related to the overall dimensions of the widget more
directly than with radial motion, but its still small, and its still
definitely not per-pixel.
You can't possibly represent fine adjustments of a 24 bit number with
an image-based screen widget. If you want precise representations, you
do what I've done, which is to add a numeric display of the number and
allow it to be set there as well.
>Ok, what if the fader is 200 pixel in height ?
>That means that we would need almost 200 pixmaps , right ?
>What if there are 30-50 of these on the screen,
>does this cause problems in terms of display performance ?
if the application is done correctly, pixmaps exist as non-duplicated
server-side resources. there is one copy in the X server that is used
to paint every location where a request to draw using that pixmap is
made. you can have 10000 of the same pixmap on the screen, and the
only extra server resources you are using are the cycles spent doing
the drawing, plus the generic resources used if, for example, they are
each in their own window (i.e. per-window overhead).
>I tried xmms and it seems to use lots of pixmaps: it is _REALLY_ slow
>(PII400 + Matrox G400 + XF 3.3) when dragging the window around or when firing
>up a few instances of the app.
xmms is generally regarded by the GTK crowd as a bastard child. havoc
pennington in particular thinks they did a horrible job of
"theme-izing" it, particularly because they completely circumvented
most of GTK (suggesting to me that they didn't understand how to use
it).
besides, no individual plugin window will have many the full set of
pixmaps. anyway, when i drag ardour or quasimodo around on the screen
(PII-450, Matrox G400 + XF3.3), even with the cables drawn (and they
are *expensive* to redraw) i would not say that its sluggish in the
way xmms is, unless the overall CPU load is way up there. not zippy
the way non-pixmap-based GUI's are, i'll grant you.
>Are my fears that the GUI will get sluggish when the screen is full of racks
>packed with sliders, displays , knobs etc unfounded ?
if the backend is implemented in the right way, yes i believe it is.
--p
This archive was generated by hypermail 2b28 : Tue Nov 28 2000 - 07:08:29 EET