Re: MPEG in GGI?
On Tue, 18 Apr 2000, Stefan Seefeld wrote: Well, from a practical point of view, how would I manage multiple input queues ? Given a list of visuals (as you seem to suggest) acting as window, I'd be forced into one thread per visual if I want to listen for events. I had such a problem with OpenAmulet - and rearchitected LibGWT to a simple scheme to solve it. Basically, the main design is the following: - real input events (those from the user) come from the root window and the application gets them THERE. The application may block on such waiting. - expose events, or internally dispatched events can come from any window event queue (I maintain a window list): they are polled. I am NOT sure at all this behavior is The Right Thing to do, but I spent a lot of time trying many solutions (except multithreading) and finally switched to this simple solution because every other solution gave me either a headache or horrible performance... Just my 0.02 Rodolphe
Re: MPEG in GGI?
On 19 Apr 2000, Marcus Sundberg wrote: teunis [EMAIL PROTECTED] writes: [clip] Okay. Can someone -please- fold the event sources in fb/... out into GII? Seriously! or something? Huh? The input sources for the fbdev target are in LibGII. No - they're initialized in fb's target. mouse, keyboard, and all. Or suggest a target with the same event sources so I could dynamically start FB/X/... if I needed graphics? What is the problem? Exactly what is it that you want to do? Be able to initialize GGI without setting a mode - leave it in default state. And to be able to go graphical if necessary. Or better to be able to activate and deactivate GGI if necessary. Say, on a playlist of mpegs some with video, some without. :) Now currently I just go graphical regardless. (yah I know I should just fold out the display/render part into another task and just select which driver...) But nonetheless it'd be very handy to be able to run the "linux console GII init" without running GGI. That automagically setup mouse, keyboard and all is -so- handy. And I've been incompetent at writing GGI and GII drivers (though I -can- fix them sometimes). G'day, eh? :) - Teunis
Re: MPEG in GGI?
Stefan Seefeld writes:
Ok, let's assume that windows listen themselfs for events. Then there
are cases where you want to draw into some 'output only' medium, a
Pixmap in X. Since Pixmaps and Windows in X are the same for the purpose
of output (drawing), they are generalized to 'Drawables'. That's precisely
what I'm asking for.
Like SDL's "surfaces" ? I.e. non-visible places to draw stuff, maybe
blitting them to the visible screen/window at some stage, right ?
LibGGI has nothing like that yet (I hope it will someday). The
closest it comes is either using a large virtual area and drawing in
the off-screen parts, or using multiple frames and drawing in the
non-visible frame(s) using ggiSet{Read,Write}Frame.
To reiterate it once more: I can completely see your point of wanting to
glue input and output together. Yet I think The individual entities for
input and output should be accessible, even instantiable, through the
public API. You should not to be forced to by an input context just because
you need an output context.
For an _application_ interface, I think it is reasonable to use this
concept of a "window" (also known as a "focus").
For something implementing that interface, like a windowing system,
yes it is reasonable for it to have direct access to the separate
input/output devices.
Think of each ggi_visual as a window if it
helps (under the X target, it actually _is_ a window). Each "VT" on
the console is also like a window (but text mode).
Well, from a practical point of view, how would I manage multiple input
queues ? Given a list of visuals (as you seem to suggest) acting as window,
I'd be forced into one thread per visual if I want to listen for events.
Have some mechanism to "join" input queues. Or poll. Or broaden the
concept of "focus" to allow multiple actual windows.
Cheers,
__
\/ Andrew Apted [EMAIL PROTECTED]
Re: MPEG in GGI?
On 2000/Apr/19, Andrew Apted wrote:
Like SDL's "surfaces" ? I.e. non-visible places to draw stuff, maybe
blitting them to the visible screen/window at some stage, right ?
LibGGI has nothing like that yet (I hope it will someday). The
closest it comes is either using a large virtual area and drawing in
the off-screen parts, or using multiple frames and drawing in the
non-visible frame(s) using ggiSet{Read,Write}Frame.
It isn't so simple. In most cases the offscreen video memory won't
be enough for you, so, some bitmaps will be there and some other not. There
should be some cache-like system that keeps in the video mémory the most
frequently used bitmaps, and some algorithms to optimize the use of the
offscreen memory, too, because you will have external fragmentation... It's
not as trivial as it seems, this is the reason why GGL doesn't have support
for this stuff yet (although you can do manually if you are brave enough, of
course).
It would be nice if GGI can do this some day...
--
__
)_) \/ / / email: mailto:[EMAIL PROTECTED]
/ \ / (_/ www : http://programacion.mundivia.es/ryu
[ GGL developer ] [ IRCore developer ] [ GPUL member ]
Re: MPEG in GGI?
Huh? The input sources for the fbdev target are in LibGII. No - they're initialized in fb's target. Initialized yes ... but you can as well simply use LibGII only if you want to get events without disturbing output. It's pretty much a matter of opening the stuff LibGGI would open for you yourself. Or better to be able to activate and deactivate GGI if necessary. Say, on a playlist of mpegs some with video, some without. :) Now currently I just go graphical regardless. That's not a too bad idea, as for X you have to anyway, as you need a window that will catch events to be used by your player (which you do want, if I get you right). Of course you could as well just open the input-stdin method, but that will only work when stuff is started from an xterm, not if it is launched by the WM. But nonetheless it'd be very handy to be able to run the "linux console GII init" without running GGI. That automagically setup mouse, keyboard and all is -so- handy. Yeah - that's one of the reasons why it's folded into LibGGI. CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: MPEG in GGI?
Andrew Apted wrote:
Personally, the idea of getting input "independently" of the output
doesn't feel right. The traditional "window" is a good abstraction,
it is a place to draw stuff for the user, and a place to receive the
feedback from the user.
But you don't listen to a window for events. You listen to the server
connection ('XDisplay') for events which *refer* to windows. A window -
as it is seen by the application - is completely unaware of events.
Ok, let's assume that windows listen themselfs for events. Then there
are cases where you want to draw into some 'output only' medium, a
Pixmap in X. Since Pixmaps and Windows in X are the same for the purpose
of output (drawing), they are generalized to 'Drawables'. That's precisely
what I'm asking for.
To reiterate it once more: I can completely see your point of wanting to
glue input and output together. Yet I think The individual entities for
input and output should be accessible, even instantiable, through the
public API. You should not to be forced to by an input context just because
you need an output context.
Think of each ggi_visual as a window if it
helps (under the X target, it actually _is_ a window). Each "VT" on
the console is also like a window (but text mode).
Well, from a practical point of view, how would I manage multiple input
queues ? Given a list of visuals (as you seem to suggest) acting as window,
I'd be forced into one thread per visual if I want to listen for events.
Stefan
___
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
___
...ich hab' noch einen Koffer in Berlin...
Re: MPEG in GGI?
I have argued in the past for a more formal separation of LibGII from LibGGI. This would decouple the event queues from ggi_visual(s). Actually they are separated. LibGII provides all event functionality. All that LibGGI does is automatically locate and load the approriate "default" event sources for a given target. After that you are free to do anything to them. Close them down (o.k. - that's not strictly supported, but could be added easily, if required) join more inputs, ... Sure, the notion of a window (as in X) is a combination since you can draw into it and be sensitive to events *for* it. A window is just a particular set of rules for representing the contents of a particular graphics context. Each window is bound to a ggi_visual in LibGWT and they route events amongst themselves just fine. Yep. That is the idea, cube3d also shows how you can multiplex the event streams. The apps on the sides of the cube get all fed by the main event stream from the visual the cube is on. But this consideration should come *after* input and output logic has been defined, i.e. a 'window' should then be constructed as, say, a pair of a drawable and a 'hot region'. This can be done easily in application context. CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: MPEG in GGI?
Andreas Beck wrote: On a different note: the Berlin project will present itself on LinuxTag in Stuttgart this year, both, with a booth as well as in a talk. Does anyone from GGI intend to show up in Stuttgart ? May be we could meet and discuss various aspects of the above... When is it ? The LinuxTag is from 29.06 to 02.07. in Stuttgart. See www.linuxtag.org for more details. Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
Re: MPEG in GGI?
According to me email software Stefan Seefeld wrote:
| Andrew Apted wrote:
| Personally, the idea of getting input "independently" of the output
| doesn't feel right. The traditional "window" is a good abstraction,
| it is a place to draw stuff for the user, and a place to receive the
| feedback from the user.
| But you don't listen to a window for events. You listen to the server
| connection ('XDisplay') for events which *refer* to windows. A window -
| as it is seen by the application - is completely unaware of events.
The ability to listen to the display as a whole not just your own
window is a source of security problems (snooping/eavesdropping/...).
Of course if you can manipulate the event queue for more than your
window, you have kissed security goodbye.
[ Which is why X tags 'fake' events, but simply looking is frequently
too much. (cf "peeping toms") ]
| Ok, let's assume that windows listen themselfs for events. Then there
| are cases where you want to draw into some 'output only' medium, a
| Pixmap in X. Since Pixmaps and Windows in X are the same for the purpose
| of output (drawing), they are generalized to 'Drawables'. That's
| precisely what I'm asking for.
| To reiterate it once more: I can completely see your point of wanting to
| glue input and output together. Yet I think The individual entities for
| input and output should be accessible, even instantiable, through the
| public API. You should not to be forced to by an input context just
| because you need an output context.
Perhaps output 'structures' need to be generalised to deal with offscreen
bitmaps, but input should only be allowed in association with its "window".
- JonT
---
Jon Tidswell
Advanced OS Technology Group / Sawmill Linux Project
IBM TJ Watson Research Center 30 Saw Mill River Road, Hawthorne, N.Y. 10532
Email: [EMAIL PROTECTED] Voice: +1 914 784 7550
Re: MPEG in GGI?
[EMAIL PROTECTED] wrote:
| But you don't listen to a window for events. You listen to the server
| connection ('XDisplay') for events which *refer* to windows. A window -
| as it is seen by the application - is completely unaware of events.
The ability to listen to the display as a whole not just your own
window is a source of security problems (snooping/eavesdropping/...).
Note that I'm not out to defend X' architecure. X' shortcomings are
one reason for berlin's existence.
[...]
Perhaps output 'structures' need to be generalised to deal with offscreen
bitmaps,
my point exactly.
but input should only be allowed in association with its "window".
what do you mean with 'its' ? Do you mean that each offscreen bitmap should
have a "window" it is associated with ? This would be what X refers to as
visual, i.e. a structure holding formatting info for pixels, colors etc.
Lots of windows can use the same visual. This makes my point since I'm arguing
that GGI's visual plays the role of all of them: drawawbles (which I might want
to have many), visuals (there might be a few) and event queues (generally
one, at least in a single threaded application).
Stefan
___
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
___
...ich hab' noch einen Koffer in Berlin...
Re: MPEG in GGI?
Once upon a time I wrote:
| But you don't listen to a window for events. You listen to the server
| connection ('XDisplay') for events which *refer* to windows. A window -
| as it is seen by the application - is completely unaware of events.
The ability to listen to the display as a whole not just your own
window is a source of security problems (snooping/eavesdropping/...).
...
Perhaps output 'structures' need to be generalised to deal with offscreen
bitmaps,
but input should only be allowed in association with its "window".
I believe Stefan Seefold responded:
| what do you mean with 'its' ? Do you mean that each offscreen bitmap
should
| have a "window" it is associated with ? This would be what X refers to as
| visual, i.e. a structure holding formatting info for pixels, colors etc.
An offscreen bitmap can't get input. :-)
[ Damn. I need to reread the GGI terminology. ]
When I say window, I mean something the user understands as a window, not
an internal data structure used for OO style GUI development.
I meant that input should _still_ be associated with a particular window,
even if output was generalised.
I see the problem in X/Win32/MacOS because the internal 'window'-list is
reused
as a user visible 'window'-list allowing applications to see 'windows' that
belong
to other applications.
And two different user-'windows' should not share event queues.
| Lots of windows can use the same visual. This makes my point since I'm
arguing
| that GGI's visual plays the role of all of them: drawawbles (which I
might want
| to have many), visuals (there might be a few) and event queues (generally
| one, at least in a single threaded application).
This has unfortunately wandered.
I was responding in the context of XDisplays, where X has multiple windows
from
multiple applications.
- JonT
Re: MPEG in GGI?
On Mon, Apr 17, 2000 at 11:39:35AM -0400, Stefan Seefeld wrote: On a different note: the Berlin project will present itself on LinuxTag in Stuttgart this year, both, with a booth as well as in a talk. Does anyone from GGI intend to show up in Stuttgart ? May be we could meet and discuss various aspects of the above... I'll be there. I would be pleased to meet someone from the list there at stuttgart. Regards, Stefan thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
Re: MPEG in GGI?
teunis [EMAIL PROTECTED] writes: On Tue, 18 Apr 2000, Andreas Beck wrote: I have argued in the past for a more formal separation of LibGII from LibGGI. This would decouple the event queues from ggi_visual(s). Actually they are separated. LibGII provides all event functionality. All that LibGGI does is automatically locate and load the approriate "default" event sources for a given target. After that you are free to do anything to them. Close them down (o.k. - that's not strictly supported, but could be added easily, if required) join more inputs, ... Hmm, one very interresting point Stefan has risen is that of how to know what visual an event is associated with in case you have joined events from several visual together. Sure you could check the origins of the event sources for each visual before joining them, but that would be really combersome. We really should have a "visual" element in the events. It would break binary compability, but as you just need a recompile I think it's worth it, unless someone has a better solution? Okay. Can someone -please- fold the event sources in fb/... out into GII? Seriously! or something? Huh? The input sources for the fbdev target are in LibGII. Or suggest a target with the same event sources so I could dynamically start FB/X/... if I needed graphics? What is the problem? Exactly what is it that you want to do? //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: MPEG in GGI?
The LinuxTag is from 29.06 to 02.07. in Stuttgart. Looks good. It's on a WE, so it might be well possible. CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: MPEG in GGI?
smpeg runs on top of SDL, which runs on top of GGI, shouldn't be
very difficult to make a wrapper that makes user think that is running
directly on top of GGI.
That's not quite the point. I think one should try to separate the
displaying part from the decompression part. I would e.g. like to have a
simple player lib that can be accessed from a special hardware-hitting
program I use to produce video output on my card, as well a a conversion
program to my native video format.
But there is a problem with C++, how can you make an extension that uses
C++ ?
I have no idea.
AFAIK if you try to resolve a function name compiled with C++ from libdl,
it doesn't run...
Maybe one has to manually demangle the function parameters ?
Maybe could be done with 'extern "C" {' ?
Probably, if the callable functions don't use C++-Features, that should
work.
Which library can play mpeg2?
Search on freshmeat for "xmovie". Should send you to the right site.
CU, ANdy
--
= Andreas Beck| Email : [EMAIL PROTECTED] =
Re: MPEG in GGI?
On Sun, 16 Apr 2000, Andreas Beck wrote: I've downloaded libsmpeg, and after seeing the API, I have seen two things that I dislike: * it needs SDL * it is in C++ Is somebody porting the code of this library to a pure C version based only on GGI maybe into an extension or something? I think there are many people here interested in having movie playing supported by GGI. Maybe they could all speak up and form a team. There are player libs out there for mpg2, mpg and qt at least. What should be done is make a LibGGI-like wrapper for them that would give them a unified API and make it easy to use them from any graphics lib, especially LibGGI. FINALLY there's interest :) *giggle* Okay, I'm going to rewrite that player I've been playing with anyways now that I'm done classes. MPEG2 - what should I use as a source? My current copy of xmovie does -not- work for colours. Everything else though. I haven't looked into it. (aside: I currently have the code for this already implemented - it plays mp3's beautifully :) [actually, with the player structured the way I have, it's more CPU-efficient with mp3's than mpg123 :] I was planning on using SMPEG for the mpeg player. The only real prob I have with this is I have mpegs that crash it :) The problems with GGI: I need events handling even when video is not enabled. (either that or FB/target needs to default to current layout and talk to the current "text" mode :) [this is the only driver I'm aware of that has a problem] - basically, if I try to watch the keyboard,mouse,... without activating GGI, Bad Things Happen. If I run GGI/fb with X running, my computer locks up. I -like- my mp3 player but I don't like crashing. And I don't always need video display. ideas? Threading is mandatory. This hasn't been a problem in FB but X... - solution: make the display a client - problem: event handling has to be in the client too - problem: sharing the rendered memory with the client efficiently Any ideas? I -do- have working code on my page at www.geocities.com/winterlion. But it's old and needs repair. I got frustrated trying to stablise the memory system so I went back to school a bit Help, ideas, anything? Does anyone else have a -better- way of writing this? G'day, eh? :) - Teunis
Re: MPEG in GGI?
Speaking about video and animation, may I come back to a suggestion I had a couple of weeks back ? I proposed to separate the 'Visual' structure into a 'Drawable' and a part concerned about event handling. The argument is quite in line with Andreas' request to refactor functionality in decompressing and drawing: Drawing and event handling have *nothing* to do with each other. My reason to ask this is that I'd like to see one day a 'drawable store' manager able to allocate any number of Drawables which I can draw into and then copy from one into another etc. However, there's always just one event listener. Berlin currently uses one Visual to draw into (via GGIMesa or libArt) but I'd like to have offscreen drawables which I can draw animations, videos and other things into before I blend them into the scene graph. Even animated pointers could be handled this way. The manager I'm talking about would then inspect the amount of accessible video memory and allocate either from that or, if it runs out of vram, from normal heap. On a different note: the Berlin project will present itself on LinuxTag in Stuttgart this year, both, with a booth as well as in a talk. Does anyone from GGI intend to show up in Stuttgart ? May be we could meet and discuss various aspects of the above... Regards,Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
Re: MPEG in GGI?
On Mon, 17 Apr 2000, Stefan Seefeld wrote: Speaking about video and animation, may I come back to a suggestion I had a couple of weeks back ? I proposed to separate the 'Visual' structure into a 'Drawable' and a part concerned about event handling. The argument is quite in line with Andreas' request to refactor functionality in decompressing and drawing: Drawing and event handling have *nothing* to do with each other. My reason to ask this is that I'd like to see one day a 'drawable store' manager able to allocate any number of Drawables which I can draw into and then copy from one into another etc. However, there's always just one event listener. [clip as I don't want to get thwapped for excessive quoting :] The manager I'm talking about would then inspect the amount of accessible video memory and allocate either from that or, if it runs out of vram, from normal heap. [okay 'nuff clipping now] Completely agreed 100% The original reason I suspect for the event handling and drawing to be merged was X, where this is necessary. It certainly is -not- in FB/KGI/... however it makes a good default starting point for the drivers. I don't know what the rest o' y'all think about this though :) G'day, eh? :) - Teunis
Re: MPEG in GGI?
teunis wrote: The original reason I suspect for the event handling and drawing to be merged was X, where this is necessary. No. Even in X you can allocate an 'XPixmap' which is a 'XDrawable' without any attached event queue. In X you need one 'XDisplay' representing the connection and all global (singleton) data such as an event queue. However, Drawables (Windows or Pixmaps) you can allocate as many as you please. Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
Re: MPEG in GGI?
Andreas Beck [EMAIL PROTECTED] writes:
But there is a problem with C++, how can you make an extension that uses
C++ ?
I have no idea.
AFAIK if you try to resolve a function name compiled with C++ from libdl,
it doesn't run...
Maybe one has to manually demangle the function parameters ?
Maybe could be done with 'extern "C" {' ?
Probably, if the callable functions don't use C++-Features, that should
work.
Well, GGIdlentry() will hardly require any C++ features, so one
simply declares it as extern "C" and there is no problem.
//Marcus
--
---+
Marcus Sundberg| http://www.stacken.kth.se/~mackan
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: MPEG in GGI?
On Mon, 17 Apr 2000, Stefan Seefeld wrote: teunis wrote: The original reason I suspect for the event handling and drawing to be merged was X, where this is necessary. No. Even in X you can allocate an 'XPixmap' which is a 'XDrawable' without any attached event queue. In X you need one 'XDisplay' representing the connection and all global (singleton) data such as an event queue. However, Drawables (Windows or Pixmaps) you can allocate as many as you please. If I understood you correctly, you want to have a visual _without_ any attached event queue, right? If so, I think there should be an option to detach it, if there isn't already one... Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: MPEG in GGI?
Andreas Beck wrote:
Maybe could be done with 'extern "C" {' ?
Probably, if the callable functions don't use C++-Features, that should
work.
*In* these functions you can use C++ features to you heart's content, as
long as the function's signature looks C-ish (i.e. you don't pass objects
etc).
Christian
--
Christian Reiniger
Coordinator/Coder, PenguinPlay (http://sunsite.auc.dk/penguinplay/)
Coordinator, LGDC(http://sunsite.auc.dk/lgdc/)
Error: Windows not found - (C)heer (P)arty (D)ance
Re: MPEG in GGI?
Stefan Seefeld [EMAIL PROTECTED] writes: Speaking about video and animation, may I come back to a suggestion I had a couple of weeks back ? I proposed to separate the 'Visual' structure into a 'Drawable' and a part concerned about event handling. The argument is quite in line with Andreas' request to refactor functionality in decompressing and drawing: Drawing and event handling have *nothing* to do with each other. Sure they do, how else would you know what happens to the visual? Expose events and such. Besides I'm not really sure what you mean by separating out the event handling from the visual structure. Of the whole ggi_visual_t there is one single pointer related to event handling, isn't that separated enough for you? My reason to ask this is that I'd like to see one day a 'drawable store' manager able to allocate any number of Drawables which I can draw into and then copy from one into another etc. However, there's always just one event listener. Berlin currently uses one Visual to draw into (via GGIMesa or libArt) but I'd like to have offscreen drawables which I can draw animations, videos and other things into before I blend them into the scene graph. Even animated pointers could be handled this way. The manager I'm talking about would then inspect the amount of accessible video memory and allocate either from that or, if it runs out of vram, from normal heap. A manager for video memory will be implemented in LibGGI soon, Andy and I have just talked about that. This will make it simple to implement an extension for offscreen images. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: MPEG in GGI?
On 18 Apr 2000, Marcus Sundberg wrote: Stefan Seefeld [EMAIL PROTECTED] writes: Speaking about video and animation, may I come back to a suggestion I had a couple of weeks back ? I proposed to separate the 'Visual' structure into a 'Drawable' and a part concerned about event handling. The argument is quite in line with Andreas' request to refactor functionality in decompressing and drawing: Drawing and event handling have *nothing* to do with each other. Sure they do, how else would you know what happens to the visual? Expose events and such. Besides I'm not really sure what you mean by separating out the event handling from the visual structure. Of the whole ggi_visual_t there is one single pointer related to event handling, isn't that separated enough for you? I don't know what Stefan's reasons are, but mine are simple. If I want to use GGI's event mechanism (and I mean GGI not GII), I'd like to be able to select (no output, use stdout for now) and then switch to (have output) at some point. Basically, I'd like to be able to enable and disable output to fbdev. I don't have this problem with any other driver (if FB gets initialized when X is running my system halts. I need the event system initialized though before that point. What can I do?) So my problem's FB/specific whereas his is a little more general. Actually I'm kind of wondering what he means too? A manager for video memory will be implemented in LibGGI soon, Andy and I have just talked about that. This will make it simple to implement an extension for offscreen images. PLEASE! :) :) :) ps: glide has one in their source... it's necessary for handling texture,double buffer, and so forth... G'day, eh? :) - Teunis
Re: MPEG in GGI?
On Mon, 17 Apr 2000, Stefan Seefeld wrote: Speaking about video and animation, may I come back to a suggestion I had a couple of weeks back ? I proposed to separate the 'Visual' structure into a 'Drawable' and a part concerned about event handling. In LibXMI, there is the concept of a drawable, which is a unit of display context which contains a ggi_visual (physical drawable context) and a set of 2D drawing context elements (line/arc styles, source/destination pixmap structs for ROP blits, etc). This sounds sort of linke what your proposal is asking for The argument is quite in line with Andreas' request to refactor functionality in decompressing and drawing: Drawing and event handling have *nothing* to do with each other. Only in the sense that they are often bound to the same unit of human/machine interaction context. The right answer is to separate out the context handling into its own API system, which is basically what GGI/GII _is_. You can argue that the context unit should not be artificially bound to the concept of graphics or events coming from input devices, as you have done, but the fact that the word 'graphics' is what the middle 'G' in 'GGI stands for is really a historical artifact at this point |-. We manage contexts, resources and events these days. My reason to ask this is that I'd like to see one day a 'drawable store' manager able to allocate any number of Drawables which I can draw into and then copy from one into another etc. However, there's always just one event listener. You can route and massage GGI events coming from one visual to others in a peer-to-peer format or a treelike hierarchical format. A 'listener' is whatever the higher-level code like Berlin wants it to be. It really makes sense to consider the ggi_visual as a universal unit of human-machine interaction context. You can encapsulate arbitrary typed subcontext units within a ggi_visual, so it is easy to use it to implement a sort of runtime polymorphic context object system! Berlin currently uses one Visual to draw into (via GGIMesa or libArt) but I'd like to have offscreen drawables which I can draw animations, videos and other things into before I blend them into the scene graph. LibXMI should have what you need. The pixmap (sub-bitmap) system is still a bit fragile, but it's all there and should work. LibGWT will let you turn a ggi_visual into a "window" (= whatever you want) and route events around between them. Even animated pointers could be handled this way. Yup. Just allocate a memory visual and use it as a pixmap cache for pointers, stipples, GUI backing storage, etc. The manager I'm talking about would then inspect the amount of accessible video memory and allocate either from that or, if it runs out of vram, from normal heap. That's different. This is sort of using the video memory as a special-purpose colored cache, and requires a LOT of help from the OS. We aren't too likely to see that too soon, so I think it makes more sense right now to just allocate framebuffer memory and manage it all in userspace. A perfectly adequate job can still be done. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
MPEG in GGI?
I've downloaded libsmpeg, and after seeing the API, I have seen two things that I dislike: * it needs SDL * it is in C++ Is somebody porting the code of this library to a pure C version based only on GGI maybe into an extension or something? -- __ )_) \/ / / email: mailto:[EMAIL PROTECTED] / \ / (_/ www : http://programacion.mundivia.es/ryu [ GGL developer ] [ IRCore developer ] [ GPUL member ]
Re: MPEG in GGI?
I've downloaded libsmpeg, and after seeing the API, I have seen two things that I dislike: * it needs SDL * it is in C++ Is somebody porting the code of this library to a pure C version based only on GGI maybe into an extension or something? I think there are many people here interested in having movie playing supported by GGI. Maybe they could all speak up and form a team. There are player libs out there for mpg2, mpg and qt at least. What should be done is make a LibGGI-like wrapper for them that would give them a unified API and make it easy to use them from any graphics lib, especially LibGGI. CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
