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
