Menu
▾
▴
libvisual-devel — libvisual mailinglist for developers
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(38) |
May
(22) |
Jun
(92) |
Jul
(101) |
Aug
(18) |
Sep
(286) |
Oct
(180) |
Nov
(73) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(18) |
Feb
(74) |
Mar
(56) |
Apr
(11) |
May
(5) |
Jun
(4) |
Jul
(20) |
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
| 2006 |
Jan
(11) |
Feb
(2) |
Mar
(10) |
Apr
(2) |
May
(1) |
Jun
|
Jul
(24) |
Aug
(11) |
Sep
(5) |
Oct
(16) |
Nov
(25) |
Dec
(8) |
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(4) |
Nov
(12) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
|
From: Dennis S. <sy...@yo...> - 2004-10-15 13:41:55
|
On Fri, 2004-10-15 at 15:35 +0200, Burkhard Plaum wrote: > >>>* Gtk1 and Gtk2 VisUI builder. > >> > >>This surprise me. I was believed that final UI building would be > >>responsibility of the programmer. > > > > It is, but since we have to write these widgets anyway, in gtk1 for > > xmms and in gtk2 for bmp, I don't think it hurts to generalise them > > in a separated libvisual-widgets package, so everyone can use them > > easily. Aka that way we make the code reusable. > > And users always have the same configuration dialogs, > no matter what application they use. Yeah, this is especially important, probably even more important than ease of development, consistention. > >>>This is our plan of universal domination, anyone comments ? > > Maybe QT widgets? I personally hate KDE/Qt but many people don't. I'm not a KDE user, but I don't hate it, everyone has their freedom of choice, and I'd like to see us everywhere, we're 'neutral' so to say. I think amarok would really like to have a QT config widget for libvisual, tho they should look into that themself :), because I'm just completely QT clueless.. heheh! Cheers, Dennis |
|
From: Burkhard P. <pl...@ip...> - 2004-10-15 13:33:33
|
>>>* Gtk1 and Gtk2 VisUI builder. >> >>This surprise me. I was believed that final UI building would be >>responsibility of the programmer. > > It is, but since we have to write these widgets anyway, in gtk1 for > xmms and in gtk2 for bmp, I don't think it hurts to generalise them > in a separated libvisual-widgets package, so everyone can use them > easily. Aka that way we make the code reusable. And users always have the same configuration dialogs, no matter what application they use. >>>This is our plan of universal domination, anyone comments ? Maybe QT widgets? I personally hate KDE/Qt but many people don't. -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
|
From: Dennis S. <sy...@yo...> - 2004-10-15 12:54:42
|
On Fri, 2004-10-15 at 12:26 +0300, Vitaly V. Bursov wrote: > On Fri, 15 Oct 2004 00:45:42 +0200 > Dennis Smit <sy...@yo...> wrote: > > > 0.2.0 goals: > > libvisual-display: > > Basic functionality working so it can be used in clients. > > A plain X11 plugin as well. > I think it's possible. More todos: > Carefull error and input params checking. Critical. > Ability to runtime configuration of render targets (VisParam?) Cheers to that, VisParam is indeed the way to do runtime configuration! You could define a set of standard parameters, and document those, I'm sure you get this nailed :) Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-10-15 12:53:49
|
Wow, very impressive, keep up the good work! On Fri, 2004-10-15 at 12:26 +0300, Vitaly V. Bursov wrote: > Take a look :) > |
|
From: Dennis S. <sy...@yo...> - 2004-10-15 12:50:57
|
On Fri, 2004-10-15 at 00:50 -0300, Duilio Javier Protti wrote: > > I mate a list of things I would like to see for 0.2.0. > > > > 0.2.0 is going to be a big release and I suspect that we're > > going to need some time to get it all out, for that reason > > we can use all the help, also with the 'little' things. > > > > > > If someone likes to add things to this list, please go > > ahead. > > > > 0.2.0 goals: > > libvisual: > > Good error reporting through VisError. > > VisVideo scaler. > > I can optimize more my ugly prototype :-) Please do so, make it modulair, so you can start different scalers using a define. like visual_video_scale (VISUAL_VIDEO_SCALE_NEAREST, ...).. I'd like to have a NEAREST and BILINAIR scaler :).. Also make sure that the actual scale function won't be super big, split up in smaller static functions, that append at the end of lv_video.c > > visual_video_overlay fixen, simplifyen. > > VisUI. > > The hardest work. Yep, will start on the basic API really soon. > > API review here and there. > > I want to start here with the const pointers I have suggested. May I > can? You can, but please send patches to the list first so I can review them! > > Portability fixes: > > The issue on freeBSD. > > This is for me. Great, thank you :) > > BIG/LITTLE ENDIAN still pending!!! > > Oh yes. My video_scaler have to define his owns macros. I doubt if it's needed for the scalar, but lv_bmp still needs to be adjusted. > > libvisual-widgets: > > Gtk1 VisUI Builder. > > Gtk2 VisUI Builder. > > Oh, now I understand... Aah, alright!, cool :). Eventually we could have a QT widget and VisVideo inbuffer method as well. > > libvisual-xmms: > > The about dialog for plugins in the same style as that > > of the xmms plugin itself. > > Good idea! You're on that I assume ? Cheers, Dennis P.S. upcoming release is going to rock guys ;) |
|
From: Dennis S. <sy...@yo...> - 2004-10-15 12:46:24
|
On Fri, 2004-10-15 at 00:49 -0300, Duilio Javier Protti wrote: > > On the list for 0.2.0: > > * Good error reporting. > > * VisUI. > > Good for both! > > > * Gtk1 and Gtk2 VisUI builder. > > This surprise me. I was believed that final UI building would be > responsibility of the programmer. It is, but since we have to write these widgets anyway, in gtk1 for xmms and in gtk2 for bmp, I don't think it hurts to generalise them in a separated libvisual-widgets package, so everyone can use them easily. Aka that way we make the code reusable. > > * API reviews. > > * Portability fixes. > > * VisVideo it's scaler. > > * Libvisual-display support in clients. > > * All kind of things that come up. > > > > When the error reporting stuff is in place, Gustavo > > will be working on the python bindings, which will > > enable the freevo (http://freevo.sf.net) project to > > use libvisual. > > > > This is our plan of universal domination, anyone comments ? > > > > Cheers, > > Dennis > > Just one more comment. I think would be better to keep release on 0.1.8. > Why? just because of the future libtool versioning system. Remember that > when we switch to the libtool system, we must start from 0.0.0. The > question is, what we will do with the current 0.1.x series? I was > thinking on just skip this series and jump to 0.2.x series (0.1.x would > became like a devel series, which exactly was it is). This way there > would be no confusse with people using old packages. Maybe it's better to use #defines for setting version anyway, so we have more control regarding that, I'd like to do a 0.2.0 to sign it's significancy, and because it will be major API incompatible. > Other possibility would be to introduce libtool versioning right now, > but I think is not the moment yet. Remember the current:revision:age > scheme of libtool (which is reflected on the package number). 'current' > must be incremented every time you change an actual API function, and > that will happen for a while on libvisual, so we will have > libvisual-10.0.4 really soon :-) Maybe we should use a different versioning scheme after all... not sure |
|
From: Dennis S. <sy...@yo...> - 2004-10-15 12:43:02
|
Thank Vitaly, he gave the hint :), but thanks anyway, I hope you enjoyed your traveling :) Cheers, Dennis On Fri, 2004-10-15 at 00:49 -0300, Duilio Javier Protti wrote: > Thanks a lot Dennis! Sorry I'm so late, I have coming back from > travel on tuesday and I was really busy from then. > > > Bye, > Duilio. |
|
From: Burkhard P. <pl...@ip...> - 2004-10-15 11:26:02
|
> This is worst case scenario. If you need to intermix different contexts, > you group gl calls anyway, don't you? I wouldn't intermix the calls, because it's nonsense. But as I said, less advanced programmers get strange ideas, when nobody watches them :-) Each API, which uses context pointers suggests, that intermixing is possible (the same way you can intermix fwrite calls with different FILE handles). So it would IMHO the best solution not to use contexts for each GL call, forbid intermixing and call glxMakeCurrent only once per frame/context. And every OpenGL programmer will be happy, because it's the way plain OpenGL works. > If there is malloc()'ed struct with dlsym()'ed function pointers, > call is like this > > mov <struct address>(,%index_reg,4), %eax > call *%eax > > or something alike. And this would be the case, if you would wrap dlsym()ed gl* functions into lvgl* calls? >>If the usage of multiple OpenGL libs cannot be avoided: >>Would it make sense to have them in separate processes? The LD_PRELOAD >>environment variable can easily force a certain libGL.so to be used, >>and OpenGL can be used as we learned it. > > That's too drain bamaging, sorry :) IMHO less brain damaging than renaming and wrapping 100s of OpenGL functions. > So, as I wrote above, there is almost no difference between staticaly > shared linkage and dlopen()'ed libraries regarding to speed. > Is it OK to load dynamically libGL? There are now 3 options: 1. Link statically 2. Link dynamically 3. dlopen Which of 1 and 2 are used, is beyond control of the libvisual developers. Because it depends on which libs (.a or .so or both) the user has installed when compiling. Normally, the linker will perfer .so until -static is used. So the question is whether to link opengl (i.e. -lGL) or dlopen() it. I strongly believe, that linking is easier, it's the standard way to use libraries and causes little overhead (and the burdon of making this work is transferred to the gcc/glibc/kernel developers). Furthermore, if some new functions appear in a later OpenGL version, plugin developers can play with them without waiting, until a new libvisual version makes them available through dlsym(). -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
|
From: Vitaly V. B. <vit...@us...> - 2004-10-15 09:26:42
|
Take a look :) -- Vitaly GPG Key ID: F95A23B9 |
|
From: Vitaly V. B. <vit...@us...> - 2004-10-15 09:25:57
|
On Fri, 15 Oct 2004 00:45:42 +0200 Dennis Smit <sy...@yo...> wrote: > 0.2.0 goals: > libvisual-display: > Basic functionality working so it can be used in clients. > A plain X11 plugin as well. I think it's possible. More todos: Carefull error and input params checking. Critical. Ability to runtime configuration of render targets (VisParam?) ...something I forgot :) -- Vitaly GPG Key ID: F95A23B9 |
|
From: Vitaly V. B. <vit...@us...> - 2004-10-15 09:19:07
|
On Thu, 14 Oct 2004 15:58:11 +0200 Burkhard Plaum <pl...@ip...> wrote: > > We can run 3 X servers independently. He-he. On different machines! > > I'll try that later. > > If you have them on different machines, the OpenGL calls will be > tunneled through the X-Protocol to different Servers. X-Protocol > calls are driver independent. > Why does the client machine need separate Gl Libs then? Hm, indeed. They should not. > > Not actually. It depends... > > If you want to do it right, you must. glXMakeCurrent is too heavy function to call it every gl call. It must not be called. Definitely. If we wrap context managing functions anyway, so it is possible to eliminate this call if it is not required. > If you pass a context pointer with each OpenGL call, > you implicitely allow people intermix calls with different contexts > (I know that it's nosense, but you never know what programmers do, > when nobody watches them) And then you must use glxMakeCurrent > in each call, which adds some cycles to the overhead calculation > below. This is worst case scenario. If you need to intermix different contexts, you group gl calls anyway, don't you? > If you forbid to intermix such calls, you don't need the context > pointers and leave things as they are in plain GLX/OpenGL. OK, I agree. context parameter is not needed. ;) I was able to run lvdisplay testing app with two independent actors running in different windows. One thing I had to add is a context_activate() calls to run() and poll_event() functions. :) > > Hm, let one function call overhead will be 100 instructions > > (VERY high overhead). > > I think 100 is realistic. I'm no assembler/CPU guru, but calling > functions via dlsym pointers seems a bit slower than direct calls. The "slow" thing with shared libraries is that the symbols should be resolved. This is done on library load or on first function call (it depends on dlopen() parameter). When the library is loaded into the process' address space the call is simple call *<addess of the function pointer> if library is statically linked it's just call <addess of the function> and if the library is statically shared linked ;) call <local_app_address> ... local_app_address: jump *<addess of the function pointer> If there is malloc()'ed struct with dlsym()'ed function pointers, call is like this mov <struct address>(,%index_reg,4), %eax call *%eax or something alike. > Overhead becomes then 4.608 ms for 1GHz CPU speed. > Assuming the lemuria framerate of ca. 30 fps, it's 13.8 %. Yes, that's a lot. > If the usage of multiple OpenGL libs cannot be avoided: > Would it make sense to have them in separate processes? The LD_PRELOAD > environment variable can easily force a certain libGL.so to be used, > and OpenGL can be used as we learned it. That's too drain bamaging, sorry :) So, as I wrote above, there is almost no difference between staticaly shared linkage and dlopen()'ed libraries regarding to speed. Is it OK to load dynamically libGL? -- Vitaly GPG Key ID: F95A23B9 |
|
From: Andrew G. <and...@bl...> - 2004-10-15 06:42:55
|
On Friday 15 October 2004 04:50, Duilio Javier Protti wrote: > > There are any plans for the website? > I still have to get the menu editors, page editors and gallery up yet... after that there may be some more stuff to do. |
|
From: Duilio J. P. <dp...@fc...> - 2004-10-15 03:35:14
|
> I mate a list of things I would like to see for 0.2.0. > > 0.2.0 is going to be a big release and I suspect that we're > going to need some time to get it all out, for that reason > we can use all the help, also with the 'little' things. > > > If someone likes to add things to this list, please go > ahead. > > 0.2.0 goals: > libvisual: > Good error reporting through VisError. > VisVideo scaler. I can optimize more my ugly prototype :-) > visual_video_overlay fixen, simplifyen. > VisUI. The hardest work. > API review here and there. I want to start here with the const pointers I have suggested. May I can? > Portability fixes: > The issue on freeBSD. This is for me. > BIG/LITTLE ENDIAN still pending!!! Oh yes. My video_scaler have to define his owns macros. > > libvisual-display: > Basic functionality working so it can be used in > clients. > A plain X11 plugin as well. > > libvisual-widgets: > Gtk1 VisUI Builder. > Gtk2 VisUI Builder. Oh, now I understand... > libvisual-bmp: > Good Beep Media Player client. with config dialog. > > libvisual-python: > Work further on the bindings (this depends on VisError). > > libvisual-xmms: > The about dialog for plugins in the same style as that > of the xmms plugin itself. Good idea! > Fiddling, stop quit stop quit, config stuff etc, stress > testing can cause crashes still > I suspect this is due thread synchronize > problems. > > libvisual-plugins: > Port corona. > Port dancing particles. > Use plugin flags. > Look at how to deal with alsa issues when the resource > 'is already used'. There are any plans for the website? Bye, Duilio. |
|
From: Duilio J. P. <dp...@fc...> - 2004-10-15 03:35:06
|
> Duilio, you wrote this, could you please have a look at it ? :) > > Cheers, > Dennis Really strange, the declaration on lv_mem.h is: #if defined(__GNUC__) && !defined(VISUAL_OS_WIN32) void *visual_mem_malloc0 (visual_size_t nbytes) __attribute_malloc__; #else void *visual_mem_malloc0 (visual_size_t nbytes); #endif /* __GNUC__ */ so apparently FreeBSD have the same problem that cygwin on win32: it is a GNU system, but it doesn't support extended attributes. I will check this in depth... Bye, Duilio. |
|
From: Duilio J. P. <dp...@fc...> - 2004-10-15 03:35:01
|
> On the list for 0.2.0: > * Good error reporting. > * VisUI. Good for both! > * Gtk1 and Gtk2 VisUI builder. This surprise me. I was believed that final UI building would be responsibility of the programmer. > * Good Beep Media Player client (this is important, they don't have > many visuals ported to their player yet, and we will instantly bring > most of the xmms collection and extras, so we can be a big player > here). I'm agree this is important. > * API reviews. > * Portability fixes. > * VisVideo it's scaler. > * Libvisual-display support in clients. > * All kind of things that come up. > > When the error reporting stuff is in place, Gustavo > will be working on the python bindings, which will > enable the freevo (http://freevo.sf.net) project to > use libvisual. > > This is our plan of universal domination, anyone comments ? > > Cheers, > Dennis Just one more comment. I think would be better to keep release on 0.1.8. Why? just because of the future libtool versioning system. Remember that when we switch to the libtool system, we must start from 0.0.0. The question is, what we will do with the current 0.1.x series? I was thinking on just skip this series and jump to 0.2.x series (0.1.x would became like a devel series, which exactly was it is). This way there would be no confusse with people using old packages. Other possibility would be to introduce libtool versioning right now, but I think is not the moment yet. Remember the current:revision:age scheme of libtool (which is reflected on the package number). 'current' must be incremented every time you change an actual API function, and that will happen for a while on libvisual, so we will have libvisual-10.0.4 really soon :-) Bye, Duilio. |
|
From: Duilio J. P. <dp...@fc...> - 2004-10-15 03:35:01
|
> Duilio and list, > > I've found why the xmms plugin crashed on plugin switch > when this was done throught the config dialog. > > It was not synchronised with threads, I've fixed that. > > Possibly there are more thread races in the > config dialog, as we really have to overview this. Thanks a lot Dennis! Sorry I'm so late, I have coming back from travel on tuesday and I was really busy from then. Bye, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-10-14 22:45:35
|
I mate a list of things I would like to see for 0.2.0.
0.2.0 is going to be a big release and I suspect that we're
going to need some time to get it all out, for that reason
we can use all the help, also with the 'little' things.
If someone likes to add things to this list, please go
ahead.
0.2.0 goals:
libvisual:
Good error reporting through VisError.
VisVideo scaler.
visual_video_overlay fixen, simplifyen.
VisUI.
API review here and there.
Portability fixes:
The issue on freeBSD.
BIG/LITTLE ENDIAN still pending!!!
libvisual-display:
Basic functionality working so it can be used in
clients.
A plain X11 plugin as well.
libvisual-widgets:
Gtk1 VisUI Builder.
Gtk2 VisUI Builder.
libvisual-bmp:
Good Beep Media Player client. with config dialog.
libvisual-python:
Work further on the bindings (this depends on VisError).
libvisual-xmms:
The about dialog for plugins in the same style as that
of the xmms plugin itself.
Fiddling, stop quit stop quit, config stuff etc, stress
testing can cause crashes still
I suspect this is due thread synchronize
problems.
libvisual-plugins:
Port corona.
Port dancing particles.
Use plugin flags.
Look at how to deal with alsa issues when the resource
'is already used'.
Cheers,
Dennis
|
|
From: Dennis S. <sy...@yo...> - 2004-10-14 20:40:37
|
Duilio, you wrote this, could you please have a look at it ? :) Cheers, Dennis On Thu, 2004-10-14 at 22:32 +0200, David Le Brun wrote: > Hi, > > I've managed to build visual and all plugin (includes gforce and nebulus > plugins) under FreeBSD. > > I've just encountered a problem with libvisual : > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../libvisual -I.. > -I../libvisual -Wall -Wno-unused-variable -Wmissing-prototypes > -Wstrict-prototypes -DPLUGPATH=\"/usr/X11R6/lib/libvisual\" -O3 -MT > lv_actor.lo -MD -MP -MF .deps/lv_actor.Tpo -c lv_actor.c -fPIC -DPIC -o > .libs/lv_actor.o > In file included from ../libvisual/lv_common.h:6, > from lv_list.h:4, > from lv_actor.c:8: > ../libvisual/lv_mem.h:11: error: syntax error before > "__attribute_malloc__" > lv_actor.c: In function `visual_actor_new': > lv_actor.c:280: warning: implicit declaration of function > `visual_mem_malloc0' > *** Error code 1 > > I've just have to remove condition to use this declaration : > void *visual_mem_malloc0 (visual_size_t nbytes); > > Informations: > libvisual-0.1.7 > FreeBSD 5.3-BETA7 > > cc -v > Using built-in specs. > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 3.4.2 [FreeBSD] 20040728 |
|
From: David Le B. <da...@dy...> - 2004-10-14 20:32:35
|
Hi,
I've managed to build visual and all plugin (includes gforce and nebulus
plugins) under FreeBSD.
I've just encountered a problem with libvisual :
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../libvisual -I..
-I../libvisual -Wall -Wno-unused-variable -Wmissing-prototypes
-Wstrict-prototypes -DPLUGPATH=\"/usr/X11R6/lib/libvisual\" -O3 -MT
lv_actor.lo -MD -MP -MF .deps/lv_actor.Tpo -c lv_actor.c -fPIC -DPIC -o
.libs/lv_actor.o
In file included from ../libvisual/lv_common.h:6,
from lv_list.h:4,
from lv_actor.c:8:
../libvisual/lv_mem.h:11: error: syntax error before
"__attribute_malloc__"
lv_actor.c: In function `visual_actor_new':
lv_actor.c:280: warning: implicit declaration of function
`visual_mem_malloc0'
*** Error code 1
I've just have to remove condition to use this declaration :
void *visual_mem_malloc0 (visual_size_t nbytes);
Informations:
libvisual-0.1.7
FreeBSD 5.3-BETA7
cc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.2 [FreeBSD] 20040728
Regards,
David
|
|
From: Dennis S. <sy...@yo...> - 2004-10-14 19:00:16
|
Heya everyone, We from the libvisual team have released a new version of libvisual! It's again much improved, as usually, changes are: libvisual-0.1.7: * Removed examples from dist, they are out dated, broken and caused problems. (Dennis) * Plugin libraries now work for real. (Dennis) * Added visual_plugin_get_api_version function. (Dennis) * Added visual_is_initialized function. (Duilio) * visual_log verboseness control. (Duilio) * visual_log custom callbacks. (Duilio) * VisRandom subsystem and plugin specific VisRandomContexts. (Dennis) * Bugfixes. (everyone) libvisual-plugins-0.1.7: New in 0.1.7: 2004-10-14: * Updates to API changes. * All plugins use the VisRandom stuff for randomizing. * New slide morph plugin. * Bugfix in flash plugin, that caused it to not work on 8bits depth. libvisual-gforce-0.1.1: New in 0.1.1: 2004-10-14: * Update to API Changes. libvisual-nebulus-0.1.4: New in 0.1.4: 2004-10-14: * Updated to API changes. (Dennis) libvisual-xmms-0.1.7: New in 0.1.7: 2004-10-14: * Global maintaince and configure dailog. (Duilio) * Many bugfixes. (Duilio) * Fixed crash on startup with GL plugin enabled. (Dennis, Vitaly) * Fixed crashes on disable/quit. (Dennis) * Fixed the WM Quit event. (Dennis, Vitaly) libvisual-bmp-0.1.0: New in 0.1.0: 2004-10-14: * Started this port of the xmms plugin. (Dennis) * Fixed crash on gl at startup. (Dennis, Vitaly) Availability: http://sourceforge.net/project/showfiles.php?group_id=106542 More explanation, news, important stuff and help at: http://libvisual.sf.net *** This release is NOT binair compatible with previous releases. *** Sorry about that, we're still in heavy development so things tend *** to change. If there are any problems or if help is needed address our mailinglists: http://libvisual.sourceforge.net/v2/index.php?page=contact Good luck, The libvisual team |
|
From: Dennis S. <sy...@yo...> - 2004-10-14 14:01:03
|
I've put online: http://www.plasser.nl/synap/libvisual/snapshots/0.1.7/ If no problems arise the next hour (yeah in a hour I'll start releasing them), these tarballs will be the final for 0.1.7. PLEASE test ;) Cheers, Dennis |
|
From: Burkhard P. <pl...@ip...> - 2004-10-14 13:54:30
|
> We can run 3 X servers independently. He-he. On different machines! > I'll try that later. If you have them on different machines, the OpenGL calls will be tunneled through the X-Protocol to different Servers. X-Protocol calls are driver independent. Why does the client machine need separate Gl Libs then? > Not actually. It depends... If you want to do it right, you must. If you pass a context pointer with each OpenGL call, you implicitely allow people intermix calls with different contexts (I know that it's nosense, but you never know what programmers do, when nobody watches them) And then you must use glxMakeCurrent in each call, which adds some cycles to the overhead calculation below. If you forbid to intermix such calls, you don't need the context pointers and leave things as they are in plain GLX/OpenGL. > Hm, let one function call overhead will be 100 instructions > (VERY high overhead). I think 100 is realistic. I'm no assembler/CPU guru, but calling functions via dlsym pointers seems a bit slower than direct calls. > It will be (less than, due to architecture) > 15000*100=1.500.000 CPU clocks. On a 1GHz it's 1.5ms. > Is that much? Ok, I made some errors before: I have 5120 Triangles, 9 OpenGL calls per triangle (3 * (glNormal + glTexCoord + glVertex)) makes 46080 calls per frame. The mesh is much too complicated to make a triangle strip. Overhead becomes then 4.608 ms for 1GHz CPU speed. Assuming the lemuria framerate of ca. 30 fps, it's 13.8 %. And the 46080 calls are not the only ones which are necessary to draw the picture. This time could be used to make better looking animations than enabling features which are useless for 99% of all users. If the usage of multiple OpenGL libs cannot be avoided: Would it make sense to have them in separate processes? The LD_PRELOAD environment variable can easily force a certain libGL.so to be used, and OpenGL can be used as we learned it. -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
|
From: Vitaly V. B. <vit...@us...> - 2004-10-14 12:45:01
|
On Thu, 14 Oct 2004 12:05:11 +0200 Burkhard Plaum <pl...@ip...> wrote: > But is this possible at all? > Did you ever made such a setup working? > How do you want to detect (at runtime), which lib should be dlopened? > > I doubt, that current X11 installations allow this at all. We can run 3 X servers independently. He-he. On different machines! I'll try that later. > > To do this gl calls should be "objectised". Like this > > lvglBegin(video, GL_LINES); > > ... > > lvglEnd(video); > > In this case, each lvgl*() function must internally call > glXMakeCurrent() or something similar. Not actually. It depends... > > to call specific function. If it's done nicely it should introduce almost > > no overhead. > > In one case lemuria draws more than 5000 triangles in one frame, along with > normal vectors and texture coordinates. > It already pushes weaker hardware to the limit. > > Propagating all these (15000+ / frame) function calls through another > lib would make it unusable for many people. Hm, let one function call overhead will be 100 instructions (VERY high overhead). It will be (less than, due to architecture) 15000*100=1.500.000 CPU clocks. On a 1GHz it's 1.5ms. Is that much? > > In theory ;) I can't see any problems with that. > Pratice looks different in this case. > > Wrapping library calls makes sense in many cases to keep things clean. > But here, we are inside the innermost rendering loop, and speed really > becomes important. CPU is not a bottleneck here. Memory, AGP buses, GPU -- yes, maybe. It must be extremly highly optimized software (for _this_ hardware only!) to make CPU a bottleneck. > Hard- and Software developers spend a lot of time, to speed optimize > OpenGL calls. So it's a bad idea to slow it down again > only for supporting some esotheric hardware configurations. Les't support a cluster! :) I'll try this in a few days. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Vitaly V. B. <vit...@us...> - 2004-10-14 12:35:51
|
On Thu, 14 Oct 2004 13:07:57 +0200 Burkhard Plaum <pl...@ip...> wrote: > Dennis Smit wrote: > > I don't think wrapping ALL gl calls is a good idea, however, it might > > be good to have some functions within lvdisplay to request glxcontext, > > pbuffers and the such, or rather make it possible to access the GLX > > stuff. > > I agree with Dennis. > Something like glxMakeCurrent MUST be wrapped, because it looks different, > on systems, which don't have GLX. Making plugins depend on GLX restricts > their usage to X11. Agree, they will be (alreary are) wrapped with context_create(), context_delete(), context_activate. > Other systems MUST have something analogous then, because OpenGL doesn't > know about windows, so some glue lib between Window system <-> OpenGL > is always needed. Even more. Non gl render targets can have contexts also. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Burkhard P. <pl...@ip...> - 2004-10-14 11:04:11
|
Dennis Smit wrote: > I don't think wrapping ALL gl calls is a good idea, however, it might > be good to have some functions within lvdisplay to request glxcontext, > pbuffers and the such, or rather make it possible to access the GLX > stuff. I agree with Dennis. Something like glxMakeCurrent MUST be wrapped, because it looks different, on systems, which don't have GLX. Making plugins depend on GLX restricts their usage to X11. Other systems MUST have something analogous then, because OpenGL doesn't know about windows, so some glue lib between Window system <-> OpenGL is always needed. But all OpenGL functions must be available directly. This also makes porting plugins to libvisual more easy. -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
10 messages has been excluded from this view by a project administrator.
